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PREFACE 


This manual is divided according to a 
three-level dependency. The subdivisions 
are noted in a three-part ascending decimal 
number (Example: 1.2.3). A change in the 
first decimal portion represents a change 
in major topic; a change in the second 
decimal portion represents the intermediate 
level; a change in the third decimal por- 
tion represents the minor level. 


In addition to prefixing the headings, the 
decimal numbers are found within the table 
of contents, on the quick-reference line on 
the bottom of each page, in the index to 
show usage of terms, and within the body of 
the manual to show cross-references. The 
quick-reference line depicts the last major 


Second Edition (November 1969) 


This edition is a major revision obsoleting H20-0594-0. 


15 SEPTEMBER 1969 


heading at the top of a page and does not 
necessarily reflect the last minor or 
intermediate level change. 


Insight into the use of this manual may be 
gained by first reading Problem Language 


Analyzer (PLAN) Users* Introduction 
(H20-0626). 


This manual includes: 


Introduction to Basic PLAN Features 

Use of PLAN for Problem Solving 

PLAN System Support for Application 
Designers 

Programming Support in PLAN 


This edition applies to Version 1, Modification Level 1, of the program product 
Problem Language Analyzer (PLAN) (1130-CX-25X, 360A-CX-26X, 360A-CX-27X) 
and to all subsequent versions and modifications until otherwise indicated in new 


editions or Technical Newsletters. 


Changes are continually made to the information herein. Therefore, before using 
this publication, consult the latest 1130 and System/360 SRL Newsletters (N20-1130, 


N20-0360) for the editions that are applicable and current. 


Copies of this and other IBM publications can be obtained through IBM branch 


offices. 


A form has been provided at the back of this publication for readers’ comments. 


If this form has been removed, address comments to: IBM Corporation, Technical 
Publications Department, 112 East Post Road, White Plains, N. Y. 10601. 
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The Problem Language Analyzer (PLAN) is 
designed to allow implementation of desir- 
able user-oriented (problem-oriented) lan- 
guages by providing a common language 
processor. Previously, problem-oriented 
languages have required independent lan- 
guage processors that were in themselves 
major implementation tasks. Even though 


highly desirable, problem-oriented lan- 
guages were implemented only for major 
applications. Reimplementation on new 
equipment has made long-term costs even 
higher. 


The PLAN system through a common language 
processor allows input to a job to _ be 
composed of several dissimilar problem 
oriented languages, all operating in a 
homogeneous environment. It also allows 
easy modification and expansion of existing 
applications and problem-oriented lan- 
guages. The PLAN concept of implementation 
makes complete machine independence of 
logic modules more easily attainable. 


Logic module loading is accomplished dynam- 
ically at execution time as defined by the 
current job description. Logic modules are 
loaded only as required and existing logic 
modules do not require modification to 
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1.0.0 INTRODUCTION 


incorporate new processing cépabilities. 
Multiple implementation of the PLAN system 
for the IBM 1130 using Disk Monitor, Ver- 
sion II and the IBM System/360 using DOS/ 
360 or OS/360, allow logic modules written 
in machine-independent ASA BASIC FORTRAN IV 
to be executed on either computer system. 


A job is described in problem-oriented 
terms ina language compatible with all 
systems. 


In general, implementation of a problem- 
solving system operating within a PLAN 
environment involves several tasks as 
defined below: 


1. Definition of the problem-oriented lan- 
guage. This definition is processed by 
PLAN to create a language dictionary. 

2. Programming of logic modules (if exist- 

ent logic modules do not suffice) to 

support the problem solution functions 

(note that this does not encompass prob- 

lems of language processing; these are 

handled by PLAN). 


3. Generation of problem-oriented language 


statements to describe the particular 
problem to be solved. 


INTRODUCTION (1.0.0) 7 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


2.0.0 SYSTEM OVERVIEW 


2-10.0 THE PLAN FUNCTION 


The Problem Language Analyzer (PLAN) is an 
application development tool that is 
designed to assist application developers 
in the implementation of problem solving 
systems by reducing development cost and 
reducing the time and effort of the imple- 
mentation and maintenance cycle. 


An introduction to the objectives of the 
PLAN system may be found in the Problem 


Language Analyzer (PLAN) Application 


Description Manual (H20-0490). It is 
recommended that it be read before 


continuing. 


PLAN, itself, does not provide the solution 
to a user's application problem. Its prime 
function is to assist the user in solving 
his problems by providing the support to 
meet the following objectives. 


e PLAN is 
tinuity of 


designed to provide for con- 

application effort across 
(1) applications, (2) machine systems, 
(3) operating systems, and (4) user 
boundaries. The concept of implement- 
ing a particular application system for 
a particular user utilizing a particu- 
lar operating system on a particular 
computing system is not considered to 
be a valid constraint in the PLAN 
environment. 


e PLAN is designed to allow paced, incre- 
mental, orderly growth of problem solv- 
ing systems by providing open-ended 
growth ability, thereby reducing the 
cost of application development. 


e PLAN is designed to provide a genera- 
lized, interactive user-oriented lan- 
guage facility in which the vocabulary 
of the language is user definable. In 
the PLAN environment, batch processing 
is treated as a special case of inter- 
active processing in which a nonre- 
sponse by the user is predetermined. 
The user may switch between batch and 
interactive as conditions dictate and 
systems allow with no loss of operating 
efficiency as long as the available 
configuration provides a supported 
interactive device. 


e PLAN is designed to reduce the regimen- 
tation required of a user in communi- 
cating the description of a problem to 
a computer. This is accomplished by 


providing a problem defining (note 
carefully that we did not say problem 
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solving) language facility that is com- 
prised of only those terms and data 
that the user chooses to use for the 
problem description. A mode of problem 
description is thus provided that does 
not require the learning of new conven- 
tions in transferring to new applica- 
tions on new systems. 


2.20.0 PERSONNEL REQUIREMENTS 


Each installation can have an open-ended 
vocabulary of commands, descriptive 
phrases, data symbols and implied standard 
data values. This allows the users of the 
system to submit problems, using a simpli- 
fied version (subset) of the vocabulary of 
the department or industry. 


PLAN includes the programs required to 
establish a local language dictionary and 
to interpret input statements using local 
dictionary entries. No additional progran- 
ming is required to define or interpret 
PLAN user-oriented language statements. 


Individuals representing three functional 
groups contribute to application develop- 
ment under PLAN. 


The System Analyst provides for input 
definition, data standards, input editing 


and validation, and program module sequenc- 
ing through language definition. The func- 
tion of the system analyst in his role as 
system designer is significantly more 
important with the PLAN concept of problem 
solving if modularity and reuse of modules 
is to be assured, since many times 
reusability cannot be appropriately mea- 
sured at the programmer and user level. 


The Programmer provides functional logic 
modules that should be segmented for maxi- 
mum flexibility. The PLAN conventions sup- 
port this flexibility by eliminating the 
need for data definition statements, pro- 
gram names, and data constants in the 
source code. The programming of algorithms 
is considerably simplified. 


The User combines the efforts of systems 
analysts and programmers at execution time 
by describing a real problem with its data. 
These statements and the language defini- 
tion determine the sequence of logic 
modules to be executed in each case. 


15 SEPTEMBER 1969 


2.25.0 PLAN OPERATING ENVIRONMENT 


Application programming can grow in a 
planned, orderly manner without reworking 
previously completed segments each time a 
new capability is added. To add new capa- 
bilities to any system simply requires (1) 
that command(s) be added to a language 
dictionary that define the new capability 
and (2) that the logic modules (if new ones 
are required) be added to a program 
library. Thus, the well-defined portions 
of any application can be made functional 
while the less precisely defined portions 
are defined and developed. 


The PLAN processor provides for processing 
of intermixed user-oriented language state- 
ments that logically define a problem to be 
solved. The free-form statements are 
executed immediately as each is’ read. 
Therefore, subsequent statements may be 
entered on the basis of results from the 
current.statement, if the statements are 
entered on a console device. In concept, 
the PLAN processor is the only mainline 
program executed. It has the potential for 
controlling processing by the loading and 
interpretation of commands and the loading 
of logic modules defined to be executed as 
a result of processing the commands. 


The conventional approach, when given a 
problem for which there is no available 
program, is to write a new mainline program 
linking available subroutines to suit the 
new problem. 


PLAN allows existing logic modules to be 
linked without new source code, simply 
following the execution sequence implied by 
the user's input statements (problem 
description). There is no compilation of 
the problem description. The logic modules 
implied by the 
linked dynamically during execution. Only 
those program modules actually required for 
execution are loaded. The logic modules to 
be executed under PLAN should be single- 
functioned; they must obey certain coding 
conventions; and they must be stored in a 
system library. 


The application logic modules are made 
machine independent by using ASA _ BASIC 


problem description are 
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FORTRAN IV language statements that include 
CALLs to standardized (PLAN) subroutines 
for linkage, direct access file processing, 
sequential input/output, utility functions, 
and to provide compatibility for functions 
that vary between IBM systems. Any pro- 
gramming language can be used, with poten- 
tial loss of machine-independence, if the 
FORTRAN coding and linkage conventions are 
maintained. 


2.30.0 IMPLEMENTATION PROCEDURES 


An illustration of the general concepts 
involved in operating the PLAN system is 
found in Figure 1. Before this can be 


considered, the 


be present: 


following facilities must 


1. An input device from which PLAN 
mands can be accepted. 


com 


2. An output device through which PLAN may 
communicate with the user. 


3. A phrase dictionary that contains PLAN 
job definitions. 


4. A library of executable programs. 


To provide these facilities to PLAN, a 
three-step process, illustrated by Figure 
1, must be executed. These steps are: 


1. Generate the required programs for the 
job by compiling/assembling the appro- 
priate source language. 


2. Define the job requirements by adding 
phrases to a PLAN phrase dictionary. 
The PLAN phrase is a definition of a 
PLAN job. It consists of a list of 
problem programs to be executed and a 
list of input. parameters and/or 
constants. 


3. Execute the necessary PLAN commands to 
run the job. A PLAN command isa 
statement that causes the PLAN system 
to invoke or execute a certain phrase 
description. 
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Figure 1. 


STEP 1 
SOURCE COMPILER 
PROGRAM 
LINK 
OBJECT EDITOR 
PROGRAM OR DISK 
UTILITY 





2.40.0 MEMORY ORGANIZATION 


During PLAN processing, that is, throughout 
the full cycle in which PLAN is in control, 


the computer memory is divided 
distinct 


into eight 


areas. These areas and the func- 


tions of the areas are defined below: 


1. 


10 


System area. This area is that portion 
of memory required for hardware use 
(in-core registers, I/O areas, etc.) 
and for operating system/monitor use. 
The size of the area is variable for 
each system. 


PLAN loader area. This area is’ that 
portion of memory permanently occupied 
by the PLAN loader. The PLAN loader 
controls program loading and command 
(phrase) processing. This array, the 
first one in blank COMMON, is 625 
32-bit words in length. 


System Switch Words. This is an area 


of switch words used for control of 
PLAN and for communication between PLAN 
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INPUT/ 
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DICTIONARY 





PRINTED 
OUTPUT 





PUNCHED 
OUTPUT 





and problem logic modules. This area 


is 15 32-bit words in length. 


Managed data array. This is an array 
protected from overlay by PLAN modules, 
residing in blank COMMON, managed by 
PLAN according to a user-defined level 
structure. The managed array may be 
defined to a size (maximum of 32,767) 
desired by the user and within the 
capacity of the computer system. 


Nonmanaged data array. The nonmanaged 
array is defined as that portion of 
blank COMMON not included in the PLAN 
loader area, the system switch area, or 
the managed data array that is pro- 
tected from overlay by the PLAN system 
modules. The combined size of the 
Managed and nonmanaged array is limited 
to a maximum that is variable on each 
computer system configuration. The 
nonmanaged array can be used for any 
working storage requirement or trans- 
mittal of data between logic modules 
where a level structure is not 
required. 
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Note that the name “communication 
array“ is used to describe the combined 
managed and nonmanaged data array. 


6. PLAN system area. In some implementa- 
tions of PLAN, additional space is 
required for residence of code to sup- 
port various functions. The size of 
this area is variable. This area is 
required by System/360 OS and DOS PLAN. 
Specification of the core size required 
may be found in the respective Opera- 
tions Manual. 


7. Application program area. This area is 
that portion of memory remaining, into 
which PLAN loads the application logic 
modules. The size of this area is 
variable; it is a function of the other 
five areas and the computer/partition 
size. 


8. FORTRAN I/0 work area. This area is 
required on DOS PLAN only and only if 
FORTRAN I/O is utilized. Its size is 
defined by the user at PLAN execution 
time but must be a minimum of 512 bytes 
if FORTRAN I/O is used. 
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Figure 2. IBM 1130 organization under PLAN 
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Figure 3. IBM DOS/360 partition 
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2.50.0 GENERAL FUNCTIONAL PLAN ORGANIZATION 


The PLAN system can be described in terms 
of five functional areas. These five areas 
are discussed below in terms of the general 
requirement for the function and the capa- 
bility provided by PLAN in the area. The 
areas are: 


Dynamic Job Supervision 
User-oriented Language Processing 
Diagnostic Supervision 
Input/Output Control 

Utility Function Control 


The reader is reminded, while reading the 
following sections, to keep in mind that 
PLAN is a system for problem solving made 
up Of many pieces. A small percentage of 
the features discussed can be split out of 
the PLAN environment and used independently 
Of PLAN. On the other hand, most of the 
facilities of PLAN need be used only to the 
degree required by the user. This system 
overview should allow the user to determine 
which features of PLAN he is interested in 
and therefore serve as a guide in directing 
his reading of the remainder of this 
manual. 


2-50.10 DYNAMIC JOB SUPERVISION 


The supposition for years has been that a 
programmer or system analyst could prede- 
termine all desired capabilities at the 
outset of planning an application system 
and therefore preplan all the required 
system logic paths. Unfortunately, this 
rarely proves to be the case. 


How many times, following tedious months of 
planning and implementation, during the 
celebration of a system finally working has 
the question "What would it take to ..." 
been asked? All too frequently, the answer 
is "restructure". Would it not then be 
desirable to have a less rigorous structure 
for application systems? 


As application areas expand and new prob- 
lems are tackled, it becomes apparent that 
total and complete problem solving struc- 
tures cannot be provided. Ina bank, for 
example; we don't know what type of trans- 
action will be next, nor do we know that a 
new type of transaction will not be 
invented tomorrow. 


In information management, we don't know 
the next question to be asked (nor, for 
that matter, can we dare assume that we 
have presupposed all the questions that may 
be postulated). In engineering, we would 
be great indeed if we could predetermine 
and plan for all combinations of problem 
parameters and design criteria. 
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Hence, the PLAN DYNAMIC loader and job 
supervisor. When a user decides to operate 
under the PLAN system, the PLAN loader is 
scheduled as a normal monitor/operating 
system job and control is passed to it. 


Control must be returned to it at the 
termination of each user*sS program module 
as long as execution in the PLAN environ- 
ment is desired. This is the first 
requi rement for running in the PLAN 
environment. Providing an exit for user's 
modules to the PLAN loader is one of two 
requirements that a user must fulfill to 
run under PLAN. Additional information on 
this function is provided at a later point 
in this overview. 


The PLAN loader is made up of two major 
components, (1) the program loader, and (2) 
the execution sequencer (hereafter called 
the pop-up list). The PLAN loader must 
remain resident throughout the entire PLAN 
run and is therefore placed in the first 
2560 bytes of BLANK COMMON. Protection of 
the PLAN loader by definition of the 
required COMMON is the second of the two 
requirements a user must satisfy to run 
under PLAN. 


The pop-up list is a programmed mechanism 
for processing program names that is quite 
analogous to the tray unloader at a company 
cafeteria. When a name is removed from the 
list, a new one pops up until the list is 


empty. When a name is added to the list, 
the existing names are pushed down until 
the list is full. Names can also be 


inserted at the bottom of the list. 


What does all of this have to do with job 


supervision? The pop-up list is used to 
indicate the sequence of programs to 
execute. The top name in the list is the 


next program to load. The user may at any 


time add names to the list or delete names 
from the list. Thus, an exchange of con- 
trol exists in the PLAN environment. The 


PLAN loader picks the top name from the 
pop-up list, the program loader places it 
in memory and transfers control to the 
program. The program executes (and modi- 
fies the pop-up list if required) and 
returns control to the PLAN loader. The 
cycle is repeated until the list is empty. 


The user is given the option of interfacing 
with the loader from his modules in several 
ways. In the following list, “modify" 
should be interpreted to mean “is given the 
facility of adding to or extracting from". 
The options are: 
e Terminate the module and return to the 
PLAN loader 
® Modify the pop-up list 
e Modify the pop-up list, terminate the 
module, and return to the PLAN loader 
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e Modify the pop-up list, save the status 
of the module currently in execution 
for future restart, terminate the 
module, and return to the PLAN loader 

e Modify the pop-up list and return to 
the PLAN loader to invoke a coexistent, 
dependent module 


How do the names get into the pop-up list 
originally? What happens when the pop-up 
list is empty? The PLAN loader interprets 
an empty list as a special signal to load 
the language interpreter to read a new 
user-oriented Language (UOL) statement from 
the PLAN input stream. (A discussion of 
language processing is contained in the 
next section.) Thus, one user-oriented 
language statement is required to initiate 
PLAN processing. 


The system analyst or language definer may 
include a program list with the definition 
of any statement. The program list is the 
definition of those programs to be executed 
whenever the particular statement is 
encountered. The language interpreter upon 
encountering the statement, retrieves the 
program list and places it in the pop-up 
list. Thus, the UOL statements may define 
the sequence of execution. Since a new 
statement is not read until the pop-up list 
is empty, the system allows the user to 


examine the output resulting from one 
Statement before entering the next. Thus, 
we find that PLAN provides for interactive 
processing. If the current PLAN input 


device is batch oriented (for example, a 
card reader), batch processing takes place. 


To illustrate the UOL statement - pop-up 
list relationship, assume that the program 
list defined for the statement FUNCTION is 
"“PROGA, PROGB, PROGC'. 
language interpreter reading the FUNCTION 
statement, the following sequence of execu- 
tions would result:. 


PROGA 

PLAN Loader 

PROGB 

PLAN Loader 

PROGC 

PLAN Loader 
PLAN Language Interpreter (to read new 
UOL statement) 


This was an elementary discussion of dynam- 
ic program loading and sequencing and does 
not cover many of the powerful options open 
to the user. It should be carefully noted 
that in the above example, PROGA, PROGB, 
and PROGC have full facility for modifying 
the pop-up list and thereby altering the 
execution sequence. For example, if PROGB 
were a graphic application module, a light 
pen detect in PROGB could have caused it to 
cancel PROGC or to schedule PROGD. The 
PLAN supervisor gives the user and his 


_the pop-up list has an entry (in this 


As a result of the 
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program the control at all times to modify 
the sequence of execution to meed the ever 
changing problem solving environment. 


Figure 5 illustrates the logic of program 
control through the PLAN pop-up list. It 
consists of six parts. Part 1 illustrates 
the system status at the time PLAN is 
invoked. PLAN is loaded by the monitor or 
Operating system from the system program 
library. The pop-up list is initialized to 
a zero (marked as empty). As a function of 
initialization, PLAN determines if the lan- 
guage definition dictionary is initialized. 
This dictionary is a direct access file 
defined as PFILE on 1130 PLAN and DFJPFIL 
on System/360 DOS and OS PLAN. It is 
referred to in this document as “PFILE". 
Then, any time the pop-up list is found to 
be empty, PSCAN (the command reader and 
scanner) is placed in the pop-up list and 
is subsequently loaded into the program 
area. This sequence, as shown in Part 2, 
illustrates that the PLAN loader accesses 
PSCAN from the system program library. 


Part 3 illustrates processing with PSCAN in 
control. A new command is read by PSCAN 
from the current PLAN input device. The 
meaning of the command is retrieved from 
the dictionary (PFILE). The definition may 
result in initialization values and data 
values being placed in the communication 
array. Program names may be placed into 
the pop-up list as a result of command 
definition. PSCAN returns control to the 
PLAN loader. When the pop-up list is not 
empty, processing continues as in Part 4. 
Part 4 illustrates processing by PLAN when 
case 
program name A). PLAN takes the top entry 
from the pop-up list and loads the desig- 
nated program from the program library into 
the program area. Once loaded into the 
program area, the module name is deleted 
from the top of the pop-up list. For 
example purposes only, to display the flow 
of events, A has been allowed to appear at 
the top of the list even though it has 
already been loaded into the program area. 
This is important to note, because in 
reality, A would have been deleted from the 
top of the pop-up list. Control transfers 
from PLAN to the loaded program, and pro- 
cessing continues as defined in Part 6. 


Part 5 illustrates processing after PLAN 
has transferred control to the program 
defined at the top of the pop-up list and 
now in the program area. Program A during 
execution may access information stored in 
the communication array and store informa- 
tion into the array for future use. It 
may, through the use of the PLAN loader 
subroutines, modify the module names in the 
pop-up list. When it has completed execu- 
tion, it must return control to the PLAN 
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loader. Processing then continues as 
defined in Part 2 or Part 4. 


The new command processor PHRAS is in 
control in Part 6. The command image (if 
an ADD PHRASE) is processed and converted 
to internal text and placed into the system 
dictionary (PFILE). The DELETE or ALTER 
PHRASE results in the deletion of the coded 
old definition of the command. At the 
termination of processing, control is again 
transferred to the PLAN loader and the 
procedure is repeated as defined in Parts 2 
and 3. 


Commands need be defined to the system only 
once. They may be altered (deleted and 
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re-added) or deleted at any time. Aftera 
command has been added to a language 
definition dictionary (maintained on disk), 
it may be executed in any sequence that is 
logically acceptable at any time within a 
PLAN command stack. 


The principles. of dynamic program loading 
through use of the PLAN loader and pop-up 
list, as defined in Figure 5, should be 
clearly understood. Following the figtre 
step-by-step again at this time may prove 
to be a worthwhile investment in terms of 
understanding material that follows in this 
manual. 
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2.50.20 PROBLEM-ORIENTED LANGUAGE 
PROCESSING 


Problem-oriented languages have been avail- 
able since the time of our earliest comput- 
ing systems. The meaning of problem- 
oriented languages is that the user com- 
municated a problem's descritpion to a 
computer in terms normally associated with 
the problem and built into the input inter- 
preter by the program designer. The terms 
and data are not necessarily those normally 
employed by the particular user. In PLAN, 
we will talk about user-oriented languages 
instead of problem-oriented languages 
because at all times the language defini- 
tion is fully accessible to the user. The 
terms, symbolic names, and data values may 
be modified to terms familiar and accept- 
able to the user. With problem-oriented 
languages as defined above, changing the 
vocabulary required programming changes in 
the language processor. 


The PLAN language processor contains only 
one programmed language statement. The 
statement, ADD PHRASE, is a bootstrap that 


allows the user to define a language that 
is meaningful to him. Just as importantly 
the language definition is always fully 


accessible to him for modification as the 
problem definition requirements change. 
The concept of a subsystem with a fixed 
language vocabulary is erased in favor of a 
system in which the language is made up of 
statements of a user's choosing and can be 
dynamically expanded and modified. The 
language can thus be truly user-oriented. 


The users communication of a problem 
description to the computer with PLAN 
statements is in the following form: 


15 SEPTEMBER 1969 


Statement Name, Data Area; 


The user‘s UOL is comprised of several 
statements; each added to the PLAN system 
by means of the ADD PHRASE statement. 


The ADD PHRASE may include definitions of: 


Statement name 

Associated program list 
Data dependency level 
Allowable data names 
Default data values 

Data mode indicators 

Data scaling information 
Definition of special 
processing 

Arithmetic expressions defining values 
Logical expressions defining values 
Logical and arithmetic tests 

Actions if the tests fail 

Logical and arithmetic formulas 


conversion 


Let*s now make another pass through the 
preceding list in another form. The fol- 
lowing narrative represents information 
that a user might provide to the system 
analyst in defining a user-oriented lan- 
guage statement. Bullets to the left of 
the narrative are meant to correspond to 
the sequence of items presented above. The 
statement definition as it would be deve- 
loped as a result of the narrative is 
included in boxes under each narrative 
section. New entries resulting at each 
step are underlined. 


e I would like to define a language statement "DESIGN SOMETHING" 


{ADD PHRASE: DESIGN SOMETHING, | 
Lo. 


e This statement must result in the computing of ... 


rn rrr 


1 
isda PHRASE: DESIGN SOMETHING, PROGRAM ‘INPUT,CALC’, | 


e Data to be defined with the statement will be identified with the names MINIMUM, 
MAXIMUM, DELTA, XVAR, MODULUS, ANGLE, YVAR, and TEST. 


| ADD PHRASE: DESIGN SOMETHING, PROGRAM ‘INPUT, CALC’, 
|MINIMUM, MAXIMUM, DELTA, XVAR, MODULUS, ANGLE, YVAR, TEST, | 
| 


e The most frequently encountered values for the variables are 0, 10E6, 100, 0, 1, 90, 


0, and NONE respectively. 
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)ADD PHRASE: DESIGN SOMETHING, PROGRAM *INPUT, CALC‘, MINIMUM 0, | 
ae 10E6, DELTA 100, XVAR 0, MODULUS 1, ANGLE 90, YVAR 0, TEST, | 


e All variables listed above may take on decimal values 


|No change to above definition| 
eee eee Sessions tages utcteas ae | 


e MODULUS should be scaled by a value of 106 


e ANGLE will be a value in degrees and should be converted to radians. 


pono + - 1 
Eee ANGLE 90=ANGLE*. 0174532965, ... | 
| eee 4 


e TEST should be set to LOGICAL TRUE if ANGLE is between zero and 90 degrees; otherwise 
to LOGICAL FALSE. 


|... TEST: (ANGLE>O) & (ANGLE<1.5707965), { 


e If TEST is FALSE, an alternate program is to be loaded to process the nonfirst 
quadrant angle. If the minimum value is greater than the maximum value, an error 
message should be issued and processing terminated. 


On nn nn rr nr 1 


ee TEST *T* APROG‘ : (ANGLE>0O) & (ANGLE<1.5707965), | 
| *FA"'MINIMUM GREATER THAN MAXIMUM‘ : (MINIMUM>MAXIMUM) | 
nn ce ce ec ee a ce ce cea ce a ne ae ee cen en a AR SS A nS DD cr DP nD sn cane Jj 


It should be noted in conclusion of this 2-50.30 DIAGNOSTIC SUPERVISION 
section that the system analyst would pro- 
vide additional data beyond that shown as a Success of any system is highly dependent 
direct result of the narrative. This upon facilities provided by the system for 
material has been added below to make the isolating and indicating user's errors 
example complete. explicitly enough to allow the source of 
the errors to be corrected. In this sense, 
an efficient diagnostic supervisor is one 
ADD PHRASE:DESIGN SOMETHING, PROGRAM of the most important attributes of a 
"INPUT, CALC', (M)MINIMUM 0, (M+1) system. . 
MAXIMUM 10E6, (M+2)DELTA100, (M+3) XVAR 
0, P+6 (M+4) MODULUS 1, (M+5) ANGLE9 0= 
ANGLE*. 017452965, I(Mt+6)N=Nt+1, (M+7) The PLAN system is highly diagnostic. In 
YVAR 0, (M+8) TEST*TA'APROG' : (ANGLE>0O) & addition to fixed diagnostic text that 
(ANGLE<1.5707965), (M+9) X#*FA'MINIMUM defines the reason for an error, a diag- 


GREATER THAN MAXIMUM® : nostic modifier is provided that gives 

(MINIMUM>MA XI MUM) ; variable data to assist in pinpointing the 
error. 

The user would not be involved the complex- The user is allowed several degrees of 


ities of the command as shown above. His flexibility in processing diagnostics. The 
use of the command would resemble that following modes of diagnostic output may be 
shown below. selected: 


® IMMEDIATE The diagnostic is printed 

DESIGN SOMETHING, MAXIMUM1000, XVAR 50, when detected. The program detecting 
ANGLE 75; the error is check-pointed (saved for 
future restart) to allow the PLAN diag- 
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nostic 
message. 


supervisor to generate the 


e STACKED The diagnostic(s) are printed 
whenever the PLAN loader determines 
that the PLAN diagnostic supervisor can 
be scheduled without a requirement for 
check-pointing an existing module. 

® QUEUED The diagnostic is written in a 
diagnostic file as indicated by the 
immediate/stacked selection. The file 
is subsequently written on the diag- 
nostic device at the appropriate PLAN 
job break or when the user requests 
such action. Thus, the user has full 
facility for preventing the intermingl- 
ing of diagnostics and normal program 
output. 


The user is also given an interface at 
modest cost to allow him to interface into 
the diagnostic supervisor. This interface 
provides a user the full benefit of IMMEDI- 
ATE, STACKED, or QUEUED processing for 
generating his diagnostics. On the 1130 
system, the cost of the IOCS to produce a 
printed diagnostic if no other printed 
output is required by the module is 
approximately 1200-1500 words depending on 
format and devices. The core required to 
interface to the PLAN diagnostic supervisor 
is approximately 500 words. Corresponding 
benefits are obtained under DOS/360 and 
OS/360. 


The third aspect of diagnostic processing 
of importance to the user is found in the 
error output processing. Many users have 
special output processing requirements. 
Format changes may be desired or a device 
not supported as the PLAN diagnostic device 
(for example, a 2260) may be the most 
appropriate output unit. Therefore, the 
user is provided an error option and data 
interface that allows him to execute his 
own error output processing module. 


In conclusion, all of the options we have 
outlined for processing system and user 
diagnostics are available to the user for 
dynamic selection. He is not forced to 
made a decision on mode (except where he 
must provide his own code for output pro- 
cessing) at compile time or even at job 
schedule time if he does not want to. Such 
decisions may be made dynamically. 


2-90.40 INPUT/OUTPUT CONTROL 


Input/output is a crucial element of virtu- 
ally every data processing job, even those 
requiring complex mathematical solutions. 
It is in this area that the universal 
languages such as FORTRAN tend to differ 
among operating systems and machines and 
where widely varying degrees of flexibility 
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and dynamic availability are found between 
different programming systems. 


The language processing function of PLAN 
significantly reduces the input processing 
associated with problem definition. The 
diagnostic supervisor normally handles’ the 
output processing required for diagnostics. 
Even then, bulk data must be read, results 
must be transmitted to appropriate output 
devices, and intermediate data must be read 
from and written in files. To fulfill 
these functions, the following three sub- 
routine sets have been provided in PLAN: 


e Sequential I/O Control 
e DYNAMIC File Control 
e PERMANENT File Control 


The sequential I/O routines process the 
unit record (readers, printers, punches, 
tapes, disks, etc.) in a continuous manner 
without the ability of random access. The 
primary objectives of this package are: 


e To provide 
compatibility 

To provide dynamic device selection 

To provide dynamic formatting selection 
To provide buffered and overlapped I/O 

To provide record reread 

To provide modular I/O programming 


cross- system I/O 


The above points can be better understood 
by examination of the following description 
of requirements and of present modes of 
operation. 


e It is essential that device codes and 
unit control information be required in 
a form that does not require reprogram- 
ming, relinkediting, or recore-imaging 
when shifting configurations. 


e The need for dynamic device selection 


can be understood by examining a pro- 
blem commonly encountered in the IBM 
1130 FORTRAN’ environment. Assune a 
user wishes to be able to _ switch 


printed output between the 1132 Printer 
and 1403 Printer and in cases of system 
malfunction switch the output to the 
console typewriter. There exists three 
alternatives, none of which are totally 
acceptable. (1) Programs can be recom- 
piled with a new *IOCS statement each 
time a device change is required. (2) 
The device codes can be set in COMMON 
at execution initialization to select 
the appropriate device routine from the 
three that were compiled. This is 
obviously wasteful of core that typic- 
ally is an already scarce commodity 
whenever I/0 is required. (3) The 
*EQUAT function can be used at core- 
image time to substitute devices. 
Severe short comings are soon noted 
here, especially when trying to substi- 
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tute a 1442-5 Punch and 2501 Reader for 
a 1442-6 Reader/Punch. A punch cannot 
be substituted for a printer even 
though only 80 characters of output are 
required. The programmer should not 
make decisions relative to the assign- 
ment of devices to functions. 
function should be left to the discre- 
tion of the user or operator to allow 
for DYNAMIC adjustment to conditions. 


e This is required in order to read a 
card in FORTRAN and format it as a 
master record if there is an x-punch in 
column 80 and as a detail record if 
there is no x-punch. 


e The buffering, overlapping, and treat- 
ment of such special indicators as 
logical end-of-file should be treated 
uniformly on all systems and should be 
available to all users. 


e The case of the x-punch as defined 
above is a special case of required 
(partial) reread. 


e® Only 1/0 and conversion routines 
required should be included with the 
user modules. 


The DYNAMIC file I/O routines communicate 
only with direct access I/O devices. It 
allows a user to define a logical drive 
(working storage on an 1130 drive or a Data 
Set on System/360) which is then dynamical- 
ly allocated and deallocated to as many as 
255 LOGICAL files. There may be up to 5 
LOGICAL drives on the 1130 and up to 8 on 
System/360. 


Space for a LOGICAL file is allocated only 


when the program logic defines a require- 
ment. Space is incrementally allocated. 
As a result, the disk space used by an 


application is only slightly greater than 
the sum of the data requirements as con- 
trasted to the sum of the maximum poten- 
tially required by each file under conven- 
tional systems. In addition, great flexi- 
bility is provided to applications since no 
arbitrary constraint need be applied at 
compile time by a programmer estimating the 
maximum file size required. 


Access 
Files 


to the file is totally random. 
are not addressed by any normal form 
of disk addressing. Rather, they are 
addressed by logical file number, by a 
relative displacement within the file, and 
by the size of the block to be transferred 
to/from the file. Thus, treatment of data 
is much like asking for a block of words 
from an out of core array. An attempt to 
read from outside the true file size causes 
the file to be closed. A write outside the 
current true file size causes an additional 
allocation of space. It should be noted 


This. 
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that in addition to removing a compile time 
requirement for file space allocation, the 
requirement for record size definition is 
eliminated. The sequence and block size 
used for writing a file has no bearing on 
what may Or may not be read. 


It*s worthwhile noting at this point that 
the 1130 Version of this package is imple- 
mented in such a way that access to the 


disk is made only when destruction of the 
buffered data is imminent instead of each 
time the user issues a write. This can 


eliminate several disk accesses and there- 
fore substantially improve performance. 


An efficient |§ logical, fixed-point, 
floating-point, or alphameric (in any com- 
bination) sort/merge in mixed ascending/ 
descending sequence is privided for the 
DYNAMIC files defined above. The sort/ 
merge is entered by a simple CALL from a 
user's module. It is basically an in-place 
sort (totally in-place on the 1130) so the 
disk requirement is minimized. Since the 
sort/merge is callable, a file can con- 
veniently be sorted into numerous required 
sequences all within a single user's 
module. In System/360, this precludes sev- 
eral entries to a job scheduler. 


The PERMANENT file I/O routines are analo- 
gous to the DYNAMIC file I/O routines 
except that no allocation is provided. The 
allocations and files are defined outside 
of PLAN but are as fully discretely 
addressable as are DYNAMIC files. 


All of the I/O support discussed in this 
section has the single basic objective of 
providing the user with efficient, compat- 
ible, I/O processing where options ineffi- 
cient or impossible to define at compile 
time are given at execution time 
(dynamically). 


2-50.50 UTILITY FUNCTION CONTROL 


Every system has a block called “everything 
else" when an attempt is made to develop a 
system organization chart. PLAN is called 
"The Application Programmer‘s Tool Bag". 
The “everything else" box in PLAN is an 
assortment of tools that can be generally 
defined as utility functions. Many func- 
tions required when developing an ap- 
plication in the PLAN environment are com- 
mon to many applications. These have been 
included in PLAN because they decrease the 
time and cost and increase the ease of 
producing application solutions. 


These functions fall into the five general 
categories of: 


e Development Aids 
e Sub-word Manipulation 
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e Array and Table Maintenance 
e Data Conversion 
e Logical Value Testing and Assignment 


The ability to examine data is a require- 
ment in the testing and execution of any 
system. PLAN provides the facility for 
dumping from internal data arrays and 
DYNAMIC or PERMANENT files and for dumping 
his current user-oriented language 
statements. 


Significant alphameric processing can be 
accomplished with high level languages if 
they have the ability to extract, mask in, 
or test at the character level. Similarly, 
program enhancement, performance improve- 
ments, and core savings can result from an 
ability to test, set, and extract bits and 
to execute test under mask operations. 
PLAN provides these functions to the PLAN 
user. 


an efficient means for 
or arrays Of in-core 


PLAN provides 
transferring strings 
data. Often, there is a large amount of 
alphameric and tabular data required in 
many applications. For example, many sys- 
tems will have an array of diagnostic 
messages that may be given. Maintenance of 
this data in core memory requires an unjus- 
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tifiable overhead. Thus, there develops a 
requirement for a maintenance and retrieval 
system for such data. The PLAN support in 
this area provides purely random processing 
of such data. This support utilizes the 
PERMANENT file routines for disk access. 
The user, by following a few simple conven- 
tions, can use these subroutines to main- 
tain any data that must be accessed by 
arrays. 


The PLAN system in its user-oriented lan- 
guage facility provides extensive numeric 
and alphameric data control. In addition, 
PLAN provides extensive LOGICAL value test- 
ing and evaluation. Because support for 
LOGICAL values is not universally available 
to users with all programming systems, PLAN 
provides the necessary LOGICAL processing 
subroutines. 


This system overview has not attempted to 
delve into the intracacies of PLAN use and 
function. Neither has it covered all of 
the facilities provided in PLAN. Careful 
understanding of the conceptual why, what, 
and how presented here will allow intelli- 
gent decisions to be made relative to what 
additional segments of this manual must be 
read and what portion of PLAN will be used. 
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This 


section defines 
ponents. 


PLAN program con- 
It provides a general description 


of the functions and purposes of the pro- 
gram modules that are required to make the 
PLAN function operate. 


No PLAN module, 
execution initiated in a manner other 


have 


other than PLAN, should 


than by appearing as a program name in the 


PLAN pop-up list. 
will result in program failure. 


Any attempt to do so 
All of 


these module names are prefixed with DFJ on 
DOS and OS PLAN. 


3.1.0 RESIDENT PLAN SYSTEM 


PLAN 


PLAN is the one "mainline" program 
for an entire series of modules 
executed to solve a problem or 
series of problems. PLAN executes 
all program loading functions and 
is therefore referred to as the 
"loader". It is the program that 
handles initialization for a PLAN 
execution and remains in control, 
either directly or indirectly, 
until control is returned to the 


‘monitor or the operating system for 


a non-PLAN job. 


It sets up the PLAN system Switch 
Words and collects the information 
necessary to communicate with other 


PLAN systems modules. If the lan- 
guage dictionary (PFILE) has not 
been initialized, it creates the 


necessary, tables and calls in PHRAS 
to add the command ADD PHRASE. 


If the language definition file is 
defined and has been initialized, 
PLAN execution is started. If the 
command analyzer (PSCAN) or the 
error-processing module (PERRS) is 
not in the library, PLAN execution 
is inhibited and control returns to 
monitor or the operating system. 


3.2.0 COMMAND ANALYZER 


PSCAN 


This module of PLAN is the command 
collector and analyzer. The com- 
mand is read from the command input 
device. PSCAN saves and restores 
the managed communication array in 
the managed array save file as 
required by the phrase level 
definition. It initializes the 
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PHRAS 


PERRS 


MANAGED communication array to 
logical FALSE each time a level 1 
command is processed. 


PSCAN collects input data values 
and stores them in the communica- 
tion array. The programs defined 
by the command definition are added 
to the pop-up list. Command- 
defined expressions are evaluated. 
Checking of any required values is 
performed and if there are no 
errors, control is returned to PLAN 
(loader) to load and execute the 
first program named in the pop-up 
list. If errors are detected, the 
system error routine (PERRS) is 
called to generate the appropriate 
diagnostics. 


PSCAN is not directly specified by 
the user for loading. It is loaded 
by PLAN, whenever no program names 
appear in the pop-up list. 


3.3.0 LANGUAGE DEFINITION ANALYZER 


This module deletes from or adds to 
a language dictionary (PFILE), pro- 
blem language command definitions. 
Standard values are converted to 
the appropriate mode (floating- 
point or fixed-point) and program 
name lists are stored. Extensive 
logical and syntax verification is 
performed before each phrase is 
stored. The system error module 
(PERRS) is called to log any 
required diagnostics. In cases 
where core size limitations prevail 
(as on the 8K 1130 System), PHUDT, 
representing the second half of 


PHRAS, is loaded as an overlay. 
PHRAS is loaded by PLAN in an 
identical manner with any user 
module. It is specified in the 


program list of the ADD PHRASE, 
ALTER PHRASE, and DELETE PHRASE 
commands. 


3.4.0 SYSTEM ERROR PROCESSOR 


This module is the system error 
processing module and is loaded to 
produce an appropriate diagnostic 
whenever control is returned to the 
loader and errors have been 
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detected or as required by 
definition of error processing. 


user 


PERRS is loaded by PLAN as a result 


Of any call to the error subrou- 
tines (ERROR, ERREX, ERRET, ERRAT, 
ERLST). 


3.5.0 PLAN UTILITIES 


GMRGA, 
GMRGB 


GSRTA, 
GSRTB 


PCDMP 


PDIAG 


PEDMP 


PFDMP 


PFIND 


(OS/DOS only) These modules perform 
the merging Of PLAN PERMANENT 
files. Their names are placed in 
the pop-up list asa result of a 
call to GMERG. 


(OS/DOS only) These modules perform 


the sorting of PLAN PERMANENT 
files. Their names are placed in 
the pop-up list as a result of a 
call to GSORT. 


This module provides a dump of the 
PLAN Switch Words and communication 
array as specified by the system 
Switch Words. This module is 
executed as a result of processing 


a DUMP COMMON, DUMP SWITCHES, DUMP 
MANAGED, or DUMP NONMANAGED 
command. 

This module maintains user- 


specified literal strings ina disk 
file. This module is executed as a 
result of processing a SET LITERAL 
command. 


This module produces a dump of the 
error messages recorded in the 
error message queue file. This 


module is executed as a result of 
processing a DUMP ERRORS command. 


This module provides a dump of PLAN 
DYNAMIC files and PLAN PERMANENT 
files. It is executed as a_ result 
of processing a DUMP DYNAMIC com- 
mand or the DUMP PERMANENT command. 


(1130 only) This module is’ the 
initialization processor for the 
DYNAMIC file find, release, and 
automatic release functions. Pack 
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PIDMP 


PIOCS 


PLENG 


PLITL 


PMRGA 


PSRTA, 
PSRTB 


PSTSV 


PTDMP 
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initialization and drive verifica- 
tion functions are performed where 
required. 


This module provides a dump of the 
phrase currently being executed. 
This module is executed only if 
user action causes its name to 
appear in the pop-up list. 


This module uses the PLAN subrou- 
tine I0CS to change PLAN system 
parameters through the use of com- 
mands. It allows the user to 
switch command input and PLAN out- 
put to new devices in the middle of 
a job stream. 
(OS/DOS only) This module varies 
the number of printed lines per 
page on an output device. The 
module is executed as a result of 
processing a ‘SET PAGE LENGTH 
command. 


This module produces a listing of 
all literals maintained in a PLAN 
literal file by the module FPDIAG. 
The LIST LITERAL command utilizes 
this module. 


This module performs the merging of 
PLAN DYNAMIC files. Its name is 


placed in the pop-up list asa 
result of a call to PMERG. 
These modules perform the sorting 


of PLAN DYNAMIC files. Their names 
are placed in the pop-up list as a 
result of a call to PSORT. 


This module saves statements when 
required. It is called in by PSCAN 
or PLAN (the loader) whenever a 
statement is to be saved for subse~ 
quent execution or the SAVE or 
EXECUTE command is processed. 


This module produces a listing ina 


tabulated format of the phrases 
defined (added by PHRAS) in the 
PLAN language definition file 


(PFILE). It is executed as a 
result of processing a DUMP PHRASES 
command. 
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The following sections define in detail the 
features, options, and restrictions asso- 
ciated with the use of the PLAN user- 
oriented languages. The section is broken 
into the nine segments listed below: 


1. PLAN Language Terminology 
This section describes the terminology 
that is used throughout this manual in 
description of the PLAN system. It 
should be read and understood before 
attempting to study subsequent sec- 


tions. The Glossary of this manual may 
also be helpful in attaining this 
understanding. 


2. PLAN Language Use 
This section describes the use of a 
language defined under PLAN. 


3. PLAN Language Definition 
This section defines the rules for 
writing a problem-oriented language 
under PLAN and describes the attainable 
capabilities. 


4. Language Definition Tutorial 
This section provides assistance to the 
system analyst-designer in the form of 
a question-and-answer tutorial on the 
generation of language definition 
statements. 


5. Standard PLAN Commands 
This section describes the commands 
that are released with every PLAN sys- 
tem because of their general utility. 


6. PLAN Subroutine Support 
This section provides a brief descrip- 
tion of subroutines available within 
PLAN. 


7. PLAN Subroutine Use 

This section provides a description of 
the PLAN loader subroutines, PLAN 
dynamic file support, PLAN error proc- 
essing subroutines, PLAN permanent file 
support, PLAN sequential file support, 
and general utility routines. Calling 
sequences and examples are provided. 


8. Programming Conventions 
This section describes the conventions 
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that a program must respect in order to 
run aS a module under PLAN. 


9. PLAN System Case Study 
This section takes the statement of a 
simple problem and carries the logic of 
solution under PLAN through two levels 
of sophistication. 


The sections above describe the details of 
the PLAN system as generally applicable to 
all implementations of PLAN. Details 
relating to restrictions of a specific 
implementation or a specific option are 
listed in the appendices of this manual as 
listed below: 

1130 


1. Appendix A: PLAN 


Specifications 


2. Appendix B: 
Specifications 


System/360 DOS PLAN 


3. Appendix C: 
Specifications 


System/360 OS PLAN 


4. Appendix D: Syntactical Organiza- 
tion of the PLAN Language 


5. Appendix E: PLAN Systems File 
Layout 

6. Appendix F: PLAN System Diagnostic 
Messages 

7. Appendix G: Compatibility 
Considerations 


8. Appendix H: 
Limits 


Summary of System 


9. Appendix I: PLAN Character Set 


10. Appendix J: System Requirements 


11. Appendix K: Functional 
Diagrams 


Analysis 


12. Appendix L: Communication 
Layout Chart 


Array 


13. Glossary 
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4.1.0 PLAN LANGUAGE TERMINOLOGY 


This section provides a general introduc- 
tion to the terminology associated with a 
PLAN user-oriented language. 


Defining a user-oriented language statement 
(command) is a one-time operation (except, 
of course, when the command requires modi- 
fication). This command definition is 
cataloged into a language definition dic- 
tionary (PFILE) that is maintained on a 
direct access device. This definition may 
then be immediately used to effect a pro- 
blem‘'s solution. 


Control of the problem solution and com- 
munication between PLAN (command analysis) 
and the application logic module is pro- 
vided by the pop-up list and the communica- 
tion array. The pop-up list is used to 
stack the list of logic module names for 
execution. The communication array allows 
for storage of arithmetic, logical, and 
literal data for transmission between PLAN 
and the system programmer's logic modules. 


In the discussions that follow, definitions 
of terms will be presented for the termino- 
logy associated with PLAN. A thorough 
understanding of these elements is required 
in the implementation of valid and effec- 
tive PLAN statements. 


4.1.1 WORD 


A word is a sequence of one or more 
alphabetic characters, without embedded 
blanks. Only the first three characters of 
the word are considered significant. Words 
of less than three characters are consid- 
ered to be padded with blanks. Examples of 
valid forms of words are given below: 


A, ABLE, ARROW, ARRAY 


Effective form (b indicates blank padding) 
of these words is: 


Abb, ABL, ARR, ARR 


Note that PLAN treats the last two words as 
being identical. 


4.1.2 PHRASE 


A phrase is a fixed sequence of one to five 
words separated by blanks. The user- 
oriented problem description language is 
built from phrases, data, and procedural 
information associated with each phrase. 
The following are examples of valid 
phrases: 


24 TERMINOLOGY (4.1.0) 


15 SEPTEMBER 1969 


DESIGN TORSION SPRING 

GRAPHIC REPORT GENERATOR 
EVALUATE STEEL FRAME BUILDING 
GRAPH 


4.1.3 OBJECT PHRASE AND VERB PHRASE 


An OBJECT phrase is an independent phrase 
defined at ADD PHRASE time. A VERB phrase 
is a dependent phrase (defined at ADD 
PHRASE time) that is used as a prefix 
modifier to an OBJECT phrase and may not be 
used alone as a phrase. The first part of 
any phrase may not be a VERB phrase. If 
"LITTLE RED WAGON" is defined as an OBJECT 
phrase, it prohibits “LITTLE", or “LITTLE 
RED" from being defined as VERB phrases. 
"LITTLE RED WAGON" may, however, be both a 
VERB and an OBJECT (nonverb) phrase. Its 
syntax determines its. use. If it stood 
alone, “LITTLE RED WAGON" would be interro- 
gated as an OBJECT (nonverb) phrase. 
However, “LITTLE RED WAGON TRAIN® would 
result in “LITTLE RED WAGON" being inter- 
preted as a verb phrase. A more detailed 
explanation Of VERB phrases and their use 
can be found in section 4.3.5. The follow- 
ing are examples of VERB phrases: 


DEFINE 

REPEAT EXECUTION 
ADD 

EXPLAIN 

ALTER 

DELETE 


4.1.4 COMMAND 


A command is a sequence of one or more 
phrases that implies a task. All but the 
last (rightmost) phrase of a command must 
be VERB phrases. A command always contains 
an OBJECT (nonverb) phrase and may contain 
up to eight VERB phrases. The first of the 
command examples shown below is an OBJECT 
phrase; the second contains a VERB and 
OBJECT phrase using phrases given in the 
above examples: 


DESIGN TORSION SPRING 
EXPLAIN DESIGN TORSION SPRING 


4.1.5 STATEMENT 


A statement is a command, optionally fol- 
lowed by data. It may contain a maximum of 
450 characters. It must be terminated with 
a semicolon (;). A PLAN input record is 80 
characters in length. The statement is 
entered in record positions 1-75. 
Continuation of text is automatic from 
position 75 of one record to position one 
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of the following record. A new statement 
may start immediately following the ter- 
Minating semicolon of the previous command. 
A record containing 80 blank characters is 
ignored. 


PLAN, upon processing a statement, loads 
logic modules that are associated with the 
phrases making up the statement. Thus, the 
sequence of statements implies the series 
of module executions that must be executed 
to complete a problem solution process. 


If a statement has a blank command the 
preceding command is implied. Note care- 
fully that only the object portion (non- 
verb) of the phrase is repeated. Example: 


SCALE, SN1, LOS5;, 
LTX* ABC*; 


SN2, LOS6; LABEL, 


The command SCALE utilizing the numeric 
data values 1 for data name SN and 5 for 
data name . LOS is executed first, followed 
by the second execution of SCALE (implied) 
which will use the values of 2 and 6 for SN 
and LOS respectively. LABEL will then be 
executed last using the literal data value 
“ABC* for data name LTX. 


The comma is always required to separate 
the command and the data even when the 
command is blank. If there is no data, the 
only punctuation required is the statement-— 


terminating semicolon. Example: 

SCALE; 
4.1.6 DATA 
Data is the set of symbols’ and values 
following the command in a statement. Data 
may be identified by name, and is logical, 
arithmetic, or literal. If data is 
unnamed, the value is stored in the posi- 


tion immediately following the previously 
stored data value. Data values follow data 
names and are not separated from the data 
names by delimiters (except optionally by 
blanks). 


A data element definition is 
follows: 


organized as 


IFISINIVI 
bee be ed 


F contains the format control, (user-exit 


control, mode control, and scale 
factor) 
S contains the communication array sub- 


script (CAP) 


N contains the data name 
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V contains the initialization values, 
check entries, and phrase-def ined 
expressions 


Examples of the three data types are: 


DEF 7, SN3 Arithmetic 
WORD" X', LTX‘ABC! Literal 
HAVE-, SWITCH+ Logical 


Data values are normally floating-point 
binary, but fixed-point binary or EBCDIC 
literals may be specified. Two values are 
reserved for logical value representation. 
They are: 


Logical FALSE = 7FFFFFFF (hexadecimal) 


Logical TRUE = 80000000 (hexadecimal) 


4.1.7 DATA NAME (DAN) 


A data name is a word that symbolizes the 
value of a particular storage location. If 
defined at phrase-definition time, it may 
be singly subscripted at phrase-execution 
time to reference a logically related 
value. All data names are assumed to refer 
to the first position of an array. 
Therefore, using data name “XYZ" is the 
equivalent of saying XYZ(1), where the 
subscript 1 is assumed. In the example 
SCALE, (20)SN 2,5,7,9, the value 9 may be 
referenced as SN(4). 


The single character E may not be used as a 
data name because of possible conflict with 
E notation in numbers. 


Care should be exercised to avoid the 
selection of data names containing the 
first three characters identical to those 
in other data names. 


4.1.8 CONSTANT (NUV) 


A constant is a signed or unsigned fixed- 


point (integer) or floating-point (real) 
decimal number. Constants may contain 
exponential modifiers but may not contain 


embedded blanks. 
stants are: 


Examples of valid con- 


1, 1., =-1, +2.5, 3.14E-1 


Two special constants are 


recognized: 


logical 


+ (logical TRUE) 
- (logical FALSE) 


4.1.9 LITERALS (SLV) 
Literals consist of any alphameric data 


(except a semicolon) bounded in the input 
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stream by single quotation marks (or the @ 
sign) or by double quotation marks. The 
double quote symbol is a unique EBCDIC 
character with no implication of two single 
quotes. Examples: 


*ABC* 
"1234" 
a69LL& 


The number of words in storage occupied by 
a particular literal is determined by ap- 
plying the following formula, where M is 
the number of literal characters and J is 
the maximum number of literal characters 
that may be stored in one ASA floating- 
point word: 


1 + (MtJ-1) / J (for single quotes) 


(M+J-1) / J (for double quotes) 
There are two ways of storing literal data. 
The particular method employed is deter- 
mined by the type of boundaries set around 
the data. If single quote marks (or the 4@ 
sign) are used, the total of the number of 
characters making up the literal is stored 
in the first word of the array (position 
indicated by the data name or CAP index, 
see 4.3.6). When double quotes bound the 
data, the character count is omitted. In 
the following examples, assume a computer 
system in which four characters can be 
stored per 32-bit word. 


*“ABCDEFGHI' 


The above literal would be stored in four 
32-bit words: 


Crh SR: Cement Gari 
[9 |ABCD] EFGH| Ibbb] 
ERR! ieee (empeenes Somer 

(bbb represents blank padding) 


Should the example be written “ABCDEFGHI" 
the literal would be stored in three 32-bit 
words: 


|ABCD| EFGH| Tbbb| 
Lh. Se | 


Literals bounded with single quotes (or @ 
Signs) are hereafter called PLAN literals 
The quote mark ending a literal must be 
identical to the quote mark beginning a 
literal. Any other quote mark is assumed 
to be a literal text character. 


4.1.10 ARITHMETIC OPERANDS (AOP). 
An arithmetic operand consists of terms and 
operators. The terms may be data names or 


constants. The operators are +, -, *, /, 
in their usual sense. Parentheses are used 
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to show the order of evaluation. The 
hierarchy of evaluation is * and / followed 


by + and-. Processing order is left-to- 
right. Mixed mode terms are allowed in an 
arithmetic operand. Evaluation of an 


arithmetic operand is done in floating- 
point mode (and rounded before storing if 
required because of truncation). 


1 
| ARITHMETIC OPERAND (aop) | 
i as a Sis nap ac a i is ct arn 4 
j{+dan} {<nuv} | 
{{ } indicates that enclosed items may | 
| be entered more than once | 
| « arithmetic operator | 
|dan data name | 
Jnuv constant | 
fm ne ern em : 
| | 
| Bt3-(C+2*D) | 
Ueda ee os Se ee ee a 


In special cases an arithmetic operand may 


be a literal or a logical constant. In 
these cases the operand may contain only 
the literal or logical constant. 

a aN CE RE Ne PO a en 1 
| SPECIAL ARITHMETIC OPERAND' (saop) | 
{| “SLV" ' 
| ‘SLv* | 
| astLva | 
| + [ 
I 7 | 
| SLV literal | 
| + designation for TRUE | 
| - designation for FALSE | 
Jaan nnn nn nnn nm { 
{| “LITERAL DATA" { 
| ‘LITERAL PLUS CHAR. CT* | 
Na a a a oe J 


4.1.11 ARITHMETIC EXPRESSIONS (AEX) 


An arithmetic expression is introduced with 
an equal sign (=) and consists of an 
arithmetic operand. An arithmetic exp:es- 
sion implies the storing of data. Arith- 
metic expressions are evaluated in 
floating-point mode. The result is stored 
in the mode indicated for the data name 
associated with the CAP in which the result 
is to be stored. Results are rounded if 
the storage mode is fixed-point. If any 
operand of an arithmetic expression has the 
value of logical TRUE or logical FALSE, the 
result of the expression evaluation is 
FALSE. 
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r 
| ARITHMETIC EXPRESSION (aex). 


|-------------------------------~--------- { 
| = aop {<aop} | 
| «+ arithmetic operator | 
| {} indicates that enclosed items may | 
| be entered more than once | 
| ----------------~------------------------ { 
| = 5*A-3*(B-12) | 
Ea ere eRe ae nS Smee Re EO RE Ne J 


The following example illustrates use of a 
phrase definition to convert input data 
values from degrees (A) to radians (B). If 
no value is given at execution time for A, 
B will be set to a logical FALSE because of 
the standard value of FALSE in A. Example: 


B=A*. 017453296, ... 


ceeAm, @ee 


If a special arithmetic operand (literal or 
logical constant) is used in an arithmetic 
expression, it may be the only operand in 
the expression. The following example 
shows the use of literals and logical 
constants in arithmetic expressions: 


A=+ (A is True) 

A=- (A is False) 
A="B" (A is Bbbb) 
A=aBa (A is 1,Bbbb) 
A="B* (A is 1,Bbbb) 


|----------------------- ~----------------- { 
"STANDARD DATA" 


| 
"STANDARD DATA‘ | 
@STANDARD DATA@ i 
| 
| 


4.1.12 LOGICAL OPERAND (LOP) 


A logical operand may be a data name or a 
relational operation. 


A relational operation consists of one of 
the relational operators “greater than" 
(>), “less than" (<), or “equal to" (=) 
preceded and followed by an arithmetic 
operand. A logical value of TRUE or FALSE 
in either arithmetic operand forces the 
result of the evaluation of a relational 
operation to be FALSE. A relational 
operand must be enclosed in parenthesis. 
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: 
{LOGICAL OPERAND (lop) | 
an { 


(aop ¢t aop) 
(dan="siv") 
‘(dan=+) 
(dan=-) 


dan data name 

aop arithmetic operand 

¢ relational operator 

slv literal value 

designation for logical TRUE 
= designation for logical FALSE 


the cs ee eee ee es ee ee gee ee 


| 
(B+5>A-D) | 
(C="ABC") | 
(D=+) | 
(F=-) | 


A special relational logical 
provided for testing literals. The rela- 
tional operator is an equal sign, preceded 
by a Single data name that may be sub- 
scripted, followed by a test mask. The 
double quote marks (card code 7-8) enclose 
the test mask. The underline character 
(card code 0-8-5) is used to indicate 
characters which are not to be tested. The 
following example illustrates a logical 
operand. to test the first character of the 
literal stored at DATA for a P in the first 
position, an N in the third character, and 
an L inthe fifth character. The literal 
mask may contain any number of characters. 


operand is 


(DATA = "P_N LL"), 


Note that testing includes only the number 
of characters in the mask, so "PN" is 
equivalent to "P_N". 


A logical operand may also test fora 
logical TRUE (DATA=+) or a logical FALSE 
(DATA=-). 


All characters in a logical operand must be 
entered in the EBCDIC code. Logical 
operands are tested for FALSE (7FFFFFFF 
Hexadecimal). If they are not FALSE, they 
are treated as TRUE. Therefore, any numer- 
ic value occurring in a logical value is 
treated as TRUE. 


4.1.13 LOGICAL EXPRESSION (LEX) 


A logical expression contains logical 
operands and operators. Logical operands 
have a value of either TRUE or FALSE, while 
logical operators are defined as "AND" (&), 
"OR™ (f)2, and "NOT" (,). All of the 
characters must be of the EBCDIC character 
set. The TRUE or FALSE result of the 
evaluation of a logical expression is 
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from evaluation in the order 
"AND". Parentheses are em- 
ployed to indicate the sequence of evalu- 
ation and also to enclose subscripts. The 
examples below illustrate the above points: 


obtained 
"NOT", "OR", 


(B>1) | (B<0) is a logical expression 
that produces a result of TRUE if B is 
greater than 1, or less than 0. 


A &§ B & 4 C is a logical expression 
that produces a result of TRUE if A and 
B are TRUE and C is FALSE. The follow- 
ing example illustrates a logical 
expression defined to test data for 
logical TRUE, logical FALSE, or a nu- 


meric value greater than 10,000. 
Example: 
(DATA=+) | (DATA=-) | (DATA>1E4) 


te a eR in mL ND TE EE SN OO AS A AE A AD aa ee 


r 
{LOGICAL EXPRESSION (lex) 


| :lopfelop} | 
{ lop logical operand | 
| ° logical operator | 
| {} indicates that enclosed items may| 
| be defined more than once 

J--------------—-—-----------—--—------—— | 
| sA]B&(C>10) | (D="XYZ") & (X=+) | 
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The following example illustrates the log- 


ical command structure, order of evalu- 
ation, and results obtained. In the 
example, “OPEN" represents a data item 
containing a logical TRUE and "CLOSE" 


represents a data item containing a logical 
FALSE: 


A:4,0PEN &  ,OPEN|,CLOSE & OPEN, pro 
duces the result of TRUE in A. ; 


LOGICAL COMMAND STRUCTURE A: 34, TRUE & , TRUE | ,FALSE & TRUE 


A: 4FALSE & FALSE | 


TRUE & TRUE 


NOTS (,) EVALUATED A: TRUE & FALSE | TRUE & TRUE 
ANDS (&) EVALUATED A: FALSE | TRUE 
OR (][) EVALUATED A: TRUE 


28 TERMINOLOGY (4.1.0) 


15 SEPTEMBER 1969 


4.2.0 PLAN LANGUAGE USE 


This section explains the use of a user- 
oriented PLAN language.. — 


Languages, defined under PLAN, may be used 
immediately after the statements have been 


added to the language dictionary. The 
following descriptions and examples 
illustrate the requirements for using a 
language. The general format of a PLAN- 


defined language statement is: 
COMMAND, DATA; 


The command is an object phrase (previously 
defined by ADD PHRASE) and from zero to 
eight prefixed verb phrases. The command 
is always terminated with a comma, except 
when the DATA section is not present. In 
this case, the semicolon is the only ter- 
Minator. Examples of valid commands are 
given below: 


THIS VERB PHRASE MODIFIES THIS OBJECT 
PHRASE, «-.; 


GRAPHIC REPORT GENERATOR; 
MACRO, «<<; 

FORTRAN PROGRAM, ..« ~;? 
DESIGN TORSION SPRING, ...; 


Omission of the command signifies that the 
previous command is to be used. However, 
the terminator must be present. Note care- 
fully that the verb portion of the phrase 
is not repeated. In the first example 
above, if THIS VERB PHRASE MODIFIES is 
assumed to be defined as a verb phrase, 
processing THIS VERB PHRASE MODIFIES THIS 
OBJECT PHRASE;,; would effectively result 
in the following execution: 


THIS VERB PHRASE MODIFIES THIS OBJECT _ 


PHRASE; 
THIS OBJECT PHRASE; 
three 


The following example specifies 
executions of the SCALE command: 


SCALE, SN1;, SN2;, SN3; 


A feature is provided to allow a user to 
substitute a ditto mark for a word ina 
command and thus eliminate redundant entry 
of words in a command. 


Use of ditto marks in a command causes 
PSCAN to pick up a word of the communica- 
tion array at phrase execution time and 
place it in the area occupied by the 
dittos. This can be useful as a shortcut 
in saving writing time if a series of 
phrases has a particular word within the 
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phrase that distinguishes that group from 
any Similar but different group. 


The first word of the communication array 
will contain the first three letters of the 
word in the phrase for which the ditto mark 


option is to be exercised. The three- 
character EBCDIC representation of the 
words to be substituted will be left- 
justified in the communication array word. 


The remaining fourth character in the word 
will always contain a blank. Example: 


ADD PHRASE: GEAR, (1)"GEA",...; 

GEAR; 

At phrase execution time CAP1 will look 
like: 


Fa Saas, Cased eiape 
{GIlTEJA| bf 
Sees Gente evens Seer 


Note: The b represents a blank. The nth 
word of the communication array is assumed 
to contain the left-justified EBCDIC repre- 
sentation of the word to be substituted for 
by the nth ditto mark in the command. 


In the following example, the input phrase 
can be shortened to one word, followed by a 
ditto mark if the letters GEA are in the 
first communication array position. The 
ADD PHRASE statement in the example is 
included solely to illustrate how use of 
this feature may be tied into language 
definition. For example: 


ADD PHRASE: GEAR, (1)"“GEA",... 


GEAR; 

DEFINE “,-.«e? (Equivalent to DEF GEA,) 
DESIGN “,.e-; (Equivalent to DES GEA,) 
ANALYZE ",.-.; (Equivalent to ANA GEA,) 
PLOT “,...; (Equivalent to PLO GEA,) 


The data section of a PLAN statement is 
free-form and requires commas and/or blanks 
only where required for clarity. The semi- 
colon (;) terminates the data section and 
the statement. 


The data section describes and defines data 
elements that are to be initialized, con- 
verted, scaled, evaluated, and stored in 
the communication array for access by logic 
modules associated with the command. 
Commas must not separate information about 
a single data item, for example, data name 
and data value. They may be used _ to 
separate different data items. 


‘4.2.1 DATA NAME (DAN) 


A data name within a command may be any 
data name defined by the ADD PHRASE for 
this command or for any preceding command 
that has been executed and upon which this 
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command is dependent (higher level). 
Example: 
ADD PHRASE: ecoe,e (30) N0,... 


The data name N is associated with communi- 
cation array position 30. 


4.2.2 SYMBOL TABLES 


A symbol table of data names associated 
with a phrase is maintained for each of 
thefour possible levels (statement depen- 
dencies) of PLAN phrases (see “Level of 
Phrase", 4.3.3 for further definition). 
The symbol table for level 1 is cleared as 
each level 1 phrase is encountered. Asa 
lower-level phrase is encountered, the sym- 
bol table for that level is initialized 
from the symbol table of the next-higher 
level. The level 2 symbol table is 
initialized to the contents of the level 1 
symbol table; level 3 to the contents. of 
level 2; and level 4 to the contents of 
level 3. Each symbol table may contain up 
to 126 symbols. These symbol tables are 
constructed at command execution time. The 
maximum number of symbols that may be 
contained in any ADD PHRASE is governed by 
the 255 16-bit words that may be contained 
in Table 3 of the phrase entry table (see 
Appendix E, 12.0.0). 


Data names from the dictionary entry for 
the current phrase are added left-to-right 
to the initialized symbol table. The sym- 
bol table is constructed in a wraparound 
fashion so that if the symbol table over- 
flows (over 126 symbols accumulate), the 
first symbols in the current symbol table 
are the first symbols to be destroyed. In 
constructing the symbol table, identical 
data names (created by higher-level 
phrases) are deleted from the table, leav- 
ing only the most currently defined value 
for each symbol. Overflow of the symbol 
table most commonly happens when processing 
many blank-level commands. An undefined 
symbol initiates a search for the symbol in 
all higher-level symbol tables. If the 
phrase level is documented to the user, he 
may use this information to eliminate 
redundant entry of data. 


Data names defined in a higher-level 
(lower-numbered) phrase upon which a lower- 
level phrase is dependent may be used in 
the lower-level phrase. In the following 
example, the data name A defined in the 
phrase ABC is used at execution time in the 
dependent phrase DEF. 


ADD PHRASE: 
ADD PHRASE: 
ABC; 

DEF, A10; 


ABC, (5)A, LEVEL1; 
DEF, LEVEL 2; 
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4.2.3 DATA VALUE (SDV,SLV) 


There are three types of data values: 
numeric, literal, and logical. When they 
are specifically assigned to a data name, 
they are positioned to the right of that 
name and may be separated by blanks from 
the name, but not by commas or any other 
punctuation, except as shown below for 
literals. 


Numeric data values are fields (constants), 
with or without a decimal point, that may 
be preceded with a sign and/or followed by 
an exponential indicator. They may not 
contain embedded blanks. The data name 
associated with the value has no _ implica- 
tions as to the type of mode (real or 


integer) in which the data value is 
entered. Examples: 

LOOK 717 

SEEK 8.65E-3 

BIG 2 

GEAR +33 


A literal data value is made up ofa 
literal positioned to the right of a data 
name. Like numeric data values, they are 
stored in the word associated with the data 
name in a left-justified manner. In the 
examples below assume that four characters 
can be stored per 32-bit word (b represents 
a blank character). 

pw 

MAIN ‘AAA* | 


TOT "MESSAGE" 


A logical data value is a value of logical 
TRUE (+) or logical FALSE (-) that is 
associated with a particular storage posi- 
tion or data name. 


The examples SWITCH+t and TEST- represent 
logical data values assigned to data names 
SWITCH and TEST. 


A data value ina statement overrides any 
phrase-defined (ADD PHRASE) initialization 
value (see “Default Values", 4.3.12). 


Use of a data name without including a data 
value at command execution time sets the 
location associated with the data name _ to 
TRUE, and should be avoided unless provided 
for by specified language and program 
module option. The following example would 
set the location associated with xXGS_ to 


TRUE: 
GRAPH, XGS; 
Several rules may be followed in reducing 


the amount of 
define data. 


information required to 
These rules are: 
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If no data name is given for a data value, 
succeeding data values are stored in adja- 
cently higher communication array positions 
(see “Communication Array Position", 4.3.6) 
in the same mode, converted by the same 
user exit, and with the same scale factors 
as defined for the last given data name. 
In the following example, if XGS is assumed 
to be defined for communication array. posi- 
tion 6, and is to be stored in floating- 
point, the results of the example would 
leave a floating-point 11 in array position 
6 and a floating-point 8.5 in array posi- 
tion 7. 


XGS11, 8.5, 


If the data value given, for which no data 
name is provided, is the first value fol- 
lowing the phrase name, the data name and 
storage mode assumed is that of the first 
data name defined for the current phrase 
and the data value will be stored in the 
associated CAP. If the first-defined 
reference is in the PLAN switch words, then 
the next definition is assumed. If there 
is no definition, the first position of the 
communication array is assumed. (Note that 
full understanding of the following example 


requires study of the section “PLAN Lan- 
guage Definition", 4.3.0.) Example: 
ADD PHRASE: ONE, (20)A, (30)B..-; 


ONE, 10; 
Stores 10 in location 20 


ADD PHRASE: TWO, (-8) ECO, (40)B...; 
TWO, 10; 

Stores 10 in location 40 

ADD PHRASE: ABC, (5) XY¥Z5, (23) POR10, 


I(7) 23 
ABC, 5, 6, PQR3 ? 


Execution of this example would leave 
floating-point 5 in array position 5, 
floating-point 6 in array position 6, 
floating-point 3 in array position 23 and 
fixed-point 2 in array position 7. 


yoo 


4.2.4 EXPRESSIONS 


PLAN statements may include expressions at 
execution time as well as at phrase defini- 
tion (ADD PHRASE) time (see “PLAN Language 
Definition" 4.3.0). Expressions are either 
arithmetic or logical. Arithmetic expres- 
sions are introduced with an equal sign 
(=); logical expressions are introduced 
with a colon. An expression must be ter- 
Minated with a comma or the phrase- 
terminating semicolon. Operands that are 
not constants must be in the current symbol 
table at the time the expression is eval- 
uated. Examples: 
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A5,A(2) = A*.017452965 
B6, C=B*39.37+F 


The above arithmetic expressions represent 
entries in execution-time statements. They 
are valid only if the variable operands, 
(A,B,F), are in the symbol table when the 
expression is evaluated. 


D: (A&B) [| (C&D) 
Ks (A + 3> F) 
Rs: (DATA=+ ) 


The above three logical expressions (they 
are introduced by a colon) may be found in 
an execution-time statement. In the first 
example, D will contain a logical value of 
TRUE (+) if either (A&B) are both TRUE or 
(CED) are both TRUE. Otherwise, it will be 
set to logical FALSE (-). K will be 
logically TRUE if the value of A+t+3 is 
greater than the value of F. However, K 
will be set to logical FALSE (-) if the 
value of either F or A is logical (TRUE or 
FALSE), or if the value of F is equal to or 
greater than the value of At3. R will 
receive a value of logical TRUE if DATA 
contains a logical TRUE; otherwise, R will 
be set to logical FALSE (-),. The following 
examples further illustrate the use of the 
previously mentioned rules: 


1. ADD PHRASE: 
(23) POR; 
SITE; 

At execution time CAP 1 
value of 13. 


SITE, 13, (6) ABC7, 


contains a 


2. ADD PHRASE: 
SITE, 13; 
Execution of this example results in a 
floating-point 13 being placed into CAP 
1. 


SITE; 


3. ADD PHRASE: 
(23) POR6; 
SITE, 5; 
Execution of this example results in a 
floating-point value of 13 being placed 
into CAP 1 and a floating-point 5 
placed into CAP 23. 


SITE, 13, (-6) ABC, 


4. ADD PHRASE: SITE, 13, (-6) ABC; 

SITE, 5; 

Execution of this example results in a 
floating-point 5 being placed into CAP 
1, overriding the phrase defined 13, 
because the switch word (-6) is not 
eligible to receive the value of 5. 
The encountering of the 5 at exééution 
time generated a search of the symbol 
table created by the ADD PHRASE state- 
ment. If no symbols are present 
(switch words are excluded), the 5 is 
placed in CAP 1. 
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4.2.5 SUBSCRIPTS 


Each data name definition is assumed to be 
the name corresponding with the first posi- 
tion of an array. Thus, using data name 
"ABC" is the equivalent of saying ABC(1), 
where the subscript one is assumed. 


Any relative communication array position 
may be referenced by using the appropriate 
subscript. In the following example, XGS 
is a data name assigned to communication 
array position 5, and YGS is a data name 


assigned to communication array position 6.) 


Each line of the example illustrates the 
correct means of entering values of XGS and 
YGS. The storage mode is assumed to be 
identical for both XGS and YGS. Example: 


XGS50, YGS60 

XGS 50,¥GS 60 
XGS 50 YGS 60 
XGS 50 xGS(2)60 
XGS 50,60 

XGS 50 60 


Arrays may be initialized to a_ single 
numeric data value at execution time by use 
of a three-parameter subscript. 


The general format of this subscript is: 
DAN(I,J,K)V 


where: 

is the initial subscript 

is the last subscript 

is the increment to the subscript 

is the initial numeric value to be 
used 


ange 


In the following example, assume A has been 
defined as equivalent to communication 
array position 72. The example indicates 
that every other position between communi- 
cation array 75 and 81 is set to zero. 


A(4,10,2)0 


In the above example, a particular area of 
storage is to be initialized with a value 
of zero (0), which is the number outside 
and to the right of the parentheses. This 
area is defined using two displacement 
values (limits) from the reference point A. 
These specific boundaries are indicated by 
the first two numbers within the paren- 
theses (4 and 10), with the first repre- 
senting the lower limit and the second the 
upper. Since A was assigned to position 
72, +.‘‘*he positions 75 to 81 (or A(4) to 
A(10)) signify the designated area. The 
third and last number within the paren- 
theses (2), is the interval at which the 
initialization value (0) is to be assigned. 
Hence, after the example is executed, the 
positions 75, 77, 79, and 81 will contain 
the value 0. Care must be taken to ensure 
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that the difference between the middle 
number and the first number (10-4) is 
evenly divisible by the third number or a 
diagnostic will result. 


4.2.6 FORMULA NUMBERS 


Formula numbers may be assigned to data 
items defined at execution time (expres- 
sions, data assignment, formulas). (See 
also “Formula Area", 4.3.20.) 


Formula numbers are introduced with a dol- 
lar sign ($) and are a numeric field in the 
range of 1 to 32,767. Formula numbers may 
precede any data item. Formula numbers 
allow branching and looping within the data 
section of a statement input. Formula 
numbers may be assigned to any allowable 
data item. In addition, the following 
special type data item entries are asso- 
ciated with formula numbers. 


Syntax :5$n, 

Meaning Formula number n is to be executed 
next (functions like a FORTRAN GO 
TO). 


Syntax $n; 

Meaning Formula number is a dummy formula 
number to allow transfer to the end 
of the command; no execution is 
implied. 


Syntax :(expression) ?S$n !5$m, 

Meaning Either the TRUE (?) or FALSE (!) 
leg (or both) of a conditional 
expression may be replaced with an 
expression number. The formula 
number (n or m) becomes a “branch 
to" indicator. 


The following illustrates use of formula 
numbers in the control of execution-time 
data definitions. Example: 


TEST, BOA1$1B=B+1, A2:(B=2)?$2, A3: 
$1,$2; 
would be executed with the following 
steps: 
BO assignment statement B=0 
Al assignment statement A=1 
$1 assignment of formula #1 to 
the expression B=B+t1 
B=Bt1 after the first execution of 
formula #1, B will have a 
value of 1 (1=0+1) 
A2 assignment statement A=2 


: (B=2) ?$2, this conditional expression 


will cause a branch to for- 
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A3 


B=Btl1 


mula #2 ($2) if B has a 
value of 2, however; now B 
has a value of 1. 

assignment statement A=3 

go to formula #1 (B=Bt1) 


formula #1 is executed giv- 
ing B a value of 2 (2=1+1) 
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assignment statement A=2 


a branch to formula # 2 will 
be executed as the condition 
being tested (B=2) is TRUE. 


formula #2 is a dummy end of 
this command. 
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4.3.0 PLAN LANGUAGE DEFINITION 


This section explains the procedures for 
defining a PLAN language statement. 


Language definition provides the phrase 
name, phrase-defined data, and other con- 
trol information required to direct the 
execution of a logical segment of a task. 
A language, once defined (Cin PFILE by 
PHRAS) remains permanently defined until 
altered or deleted by processing an ALTER 
PHRASE or DELETE PHRASE command. The fol- 
lowing discussion treats each possible ele- 
ment of a language statement and its 
implied effect on the use of and generation 
of problem solution logic modules. A PLAN 
problem-oriented language is defined by 
phrases; the newly loaded system has’ the 
capability only of adding phrases through 
the use of the basic system command ADD 
PHRASE. As soon as new commands are added, 
they may be included in the PLAN input 
stream for execution, as defined in the 
preceding section. The general format for 
adding phrases is: 


ADD PHRASE: 
DEFINED DATA; 


PHRASE NAME, PHRASE- 


A defined phrase may be deleted from the 
language dictionary by the use of the 
DELETE PHRASE command. If the phrase to be 
deleted is a VERB phrase, the specification 
word VERB must be used. Format of the 
command is as defined for ADD PHRASE, 
except that there is no phrase-defined 
data. Example: 


DELETE PHRASE: 
DELETE PHRASE: 


THIS PHRASE; 
THAT PHRASE, VERB; 


The ALTER PHRASE command is a combination 
of a DELETE PHRASE followed by an ADD 
PHRASE. Partial modification of a phrase 
in PFILE is not implied. Therefore, the 
ALTER PHRASE must follow the exact format 
of the ADD PHRASE. Example: 


ALTER PHRASE: 
DEFINED DATA; 


PHRASE NAME, NEW PHRASE- 


In the above example PHRASE NAME specifies 
both the name of the phrase to be deleted 
and the name of the new phrase to be added. 
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If the ALTER PHRASE is used for a nonexist- 
ent phrase, a diagnostic will be produced 
indicating that the phrase to be deleted 
cannot be found but the phrase to be added 
will be successfully entered into the lan- 
guage dictionary. 


Note that phrase definition commands are 
always followed with a colon and the phrase 
is terminated with a semicolon. Any state- 
ment encountered by PSCAN that has the 
command followed by a colon is not proc- 
essed beyond the colon. If the phrase is 
interpreted to be ADD PHRASE, ALTER PHRASE, 
or DELETE PHRASE, the program name PHRAS is 
placed in the pop-up loader to be executed 
next. BCD or EBCDIC character coding may 
be used where multiple coding conventions 
exist, except where otherwise specified. 


4.3.1 PHRASE NAME 


Phrase names 
rules under 
4.1.0. 
are: 


follow the previously listed 
"PLAN Language Terminology", 
Important points for naming phrases 


1. They may contain from one to five 
words. 


2. Words are truncated after three 
alphabetic characters. Care should 
be exercised in using words of more 
than three characters to avoid 
creation of undesired synonyms with 
other words. 


3. Words must contain only alphabetic 
characters. 


4. The phrase name is terminated with 
a comma (if phrase-defined data 
does not exist, the comma may be 
omitted). 


5. Words of less than three characters 
are assumed to contain blank pad- 
ding to three characters. 


6. The same sequence of words used in 
a VERB phrase name may not be used 
as the first part of any other 
phrase name. 
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4.3.2 PHRASE-DEFINED DATA 


The following general categories are speci- 
fied as phrase-defined data: 


1. Level of phrase 
2. Program list 
3. Verb designation and program list 
4. Data elements 
a. Data name 
b. Default values 
c. Scale factors 
d. Mode 
e. Communication array position 
f. Checking rules 
g- Expressions to evaluate 
5. Statement-saving specifications 
6. User-exit programs 
7. Exit 


8. Formula area 


4.3.3 LEVEL OF PHRASE 


The input interpreter has the ability to 
work with up to four levels of statement 
dependence. This permits convenient, con- 
cise input because data entered at a higher 


level is made automatically available at a 
lower level. PLAN also effects correct 
data context during error recovery and 


input validation. Execution errors need 
result only in an abort of that portion of 
the job affected by the invalid data. 
Definition of a problem solution may often 
be defined in logical, indented outline 
form. Example: 


I. JOB NAME 
A. Major Activity 
1. Intermediate Activity 1 
a. Detail 
b. Detail 
2. Intermediate Activity 2 


a. Detail 


B. Major Activity 


It. JOB NAME 
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The PLAN commands may have a level assign- 
ment corresponding to this outline. State- 
ments at level 1 (I, II, etc.) are com- 
pletely independent of all other state- 
ments. Level 2 (A, B, etc.), level 3 (1, 
2), and level 4 (a,b,etc.) statements are 
dependent upon the accumulation of informa- 
tion provided by the preceding statement of 
each higher (lower-numbered) level. 


The PLAN level structure processor saves 
and forwards data (managed array) from each 
statement to its logical successors. The 
logical sanctity of the managed array is 
preserved by PLAN through saving, and 
restoring, the proper data context. 


Commands, that have no assigned level, are 
executed at the level of the previously 
executed command. 


An error in a command, at any level, of the 
severity to demand cessation of processing 
when operating with a level concept, need 
cause only skipping of affected commands. 
Thus, an error at any level results in 
skipping of commands only until a command 
of equal or higk2r level is encountered. 
The managed data array is then initialized 
to represent the proper level of data. All 
blank-level commands following a command in 
error are skipped except when the error 
command is blank-level. In that case, only 
the blank-level command in error is 
aborted. 


A level 0 command must be the first command 
processed when entering the PLAN system. 
ADD PHRASE, ALTER PHRASE, DELETE PHRASE, 
and PLAN JOB are_ system level (level 0) 
commands. 


A level 0 command causes all system default 
options to be set. System options (see 
"Switch Words", 4.3.21) may also be set to 
the user's specifications. The standard 
PLAN command “PLAN JOB;" is recommended as 
a level 0 command. A level 0 command must 
always be followed by a level 1 command or 
another level 0 command. A level 0 command 
may be introduced at any position within a 
PLAN job stack to reset the system standard 
options. 


The managed array, the size of which is 
indicated in Switch Word 10, is set to the 
value of logical FALSE (7FFFFFFF) whenever 
a level 1 phrase is encountered. 


If a value is specified for the keyword 


LEVEL, it must be 0, 1, 2, 3, or 4. 
Example: 
ADD PHRASE: SOME PHRAS, LEVEL1, ...; 


Level 2, 3, and 4 commands are each depen- 
dent on the preceding higher-level (lower- 
numbered) command. 
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The level indicator is placed in the phrase 
dictionary (PFILE) to indicate the logical 
position of this phrase in a sequence of 


dependent statements. If no level is 
assigned, the level is considered to be 
blank. Blank-level phrases are processed 


as continuations of the last phrase without 
forcing a level test. A level test, fol- 
lowing the rules indicated below, is forced 
whenever a phrase is processed that has a 
level designation. Two basic functions are 
fulfilled by the level test. If an error 
occurs in a phrase, recovery can be made at 
a point in processing where dependent data 
is not in error, that is, at a phrase of 
equal or higher level. Secondly, the 
managed communication array can be saved 
and restored so that it always includes 
data of only those phrases upon which this 
phrase depends. If the managed array 
length (Switch Word 10) is set to zero, the 
data management function is bypassed, but 
error control processing will still be 
effected. 


In all discussions, references to the level 
of the preceding phrase should be inter- 
preted to mean “the preceding phrase with 
an explicit level indication". Thus, 
blank-level phrases are significant only to 
the degree that they are implicitly 
assigned the level of the preceding phrase. 
The following rules govern the saving and 
restoring of the managed communication 
array: 


1. The communication array is copied onto 
disk if a level 1, 2, or 3 phrase has 
just been executed and a phrase of 
lower level has been accepted from the 
current input device. The communica- 
tion array resulting from the execution 
of a level 4 command is never’ saved 
because there are no lower-level com 
mands. In other words, an error in a 
level 4 command causes the communica- 
tion array to be restored at the level 
3 status. Note that there must be a 
user-defined file (PDATA on 1130 PLAN 
and PLMANFIL on System/360 PLAN) if the 
communication array is to be saved. 
The appropriate Operations Manual con- 
tains the necessary instructions for 
defining this file. 


2. Upon reading a phrase of equal or 
higher-level as compared with the level 
of the phrase just executed, the 
Managed communication array is restored 


from the disk save area which is asso- 
ciated with the level that is one 
greater than the level just read. 


Assume we have just finished processing 
a level 3 command and have just read a 
new level 3 command. The communication 
array would be restored to the status 
as of the last level 2 command. The 
last level 2 command was the one that 
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had generated data results used by the 
old level 3 command. It is now pos- 
Sible for the new level 3 command to 
use the same level 2 data. The reader 
should be able to see how the PLAN 
level structure facilitates interactive 
processing. 


3. The data from previous equal or lower- 
level (higher-numbered) phrases can 
never be seen in the managed communica- 
tion array. 


4. If the new level is 1 there is no 
restore from level 0, nor is there ever 
a save of level 0. 


The following example illustrates the rules 
stated above. Five phrase definitions were 
entered into PFILE by the ADD PHRASE com- 
mands below: 


ADD PHRASE: A, LEV 1, 1(1)S0,T0,00,V0,WO0; 
ADD PHRASE: B, LEVEL 2; 

ADD PHRASE: C, LEVEL 3; 

ADD PHRASE: D, LEVEL 4; 

ADD PHRASE: ; 


The status of the communication array is 
shown as it would exist following the 
execution of the commands listed in the 
table. These commands are issued in the 
order listed. Note: The hyphens shown in 
the table indicate that when an error 
occurs, the user cannot rely on the _ fact 
that previously stored data is still avail- 
able. Execution of the first command (A;) 
causes the first five words of the communi- 
cation array to be set to zero. 
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When errors that result in a phrase abort 
are encountered, error indicators are set 
to inhibit execution of any phrase until a 
phrase of equal or higher level is encoun- 
tered. All phrases are, however, checked 
for proper syntax, and if errors are found, 
PLAN diagnostics are generated. 


Data names defined in a phrase are avail- 
able to phrases of lower level. Thus, a 
data name defined in level 1 may be used by 
a dependent level 2, level 3, level 4, or 
blank-level phrase without redefinition. 
Any new definition in a phrase supersedes 
an identical data name defined in a higher- 
level phrase. Therefore, the same data 
name may be used in every phrase. A new 
data name table is initialized only when a 
level 1 phrase is’ encountered. For a 
discussion of symbol tables under level 
control see 4.3.25 and Figure 9. 
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4.3.4 PROGRAM LIST 


A program list may be associated with a 
particular phrase. This list is added to 
the pop-up list before the program list 
associated with check entries. The keyword 
PROGRAMS introduces a PLAN literal contain- 
ing the program names to be placed in the 
pop-up list. The pop-up list is loaded so 
that the first program named will be 
executed first. If a program list is not 
specified for a phrase, the pop-up list is 
not changed when the phrase is encountered. 
A new command will be processed immediately 
and PSCAN will not require reloading. 


In the following example, programs entitled 
"M0730", “"MO745", and “M0737" are to be 
executed in that order when the phrase 
“NAME” is processed. 


ADD PHR: NAME, PRO‘'MO730, M0745, 
MO737° 2.23 
Three EBCDIC special characters are also 


recognized as valid entries in the program 
list. These EBCDIC characters must be 
left-justified in a PLAN double-word (64 
bits) if they are to be added to the pop-up 
load list through user programming. it, 
however, they are to be added to the pop-up 
load list through use of the specification 
word PROGRAMS‘'...‘, PLAN will ensure’ that 
these special characters are inserted 
correctly. These entries are: 


* indicates a return to ae checkpointed 
program (see "LCHEX" under “Program 
Linkage Routines", 5.11.1). 

( indicates the start of coexistent pro- 
gram grouping 

) indicates the end of coexistent program 
grouping 


See Appendix B (DOS), “Core Management", 
9.7.0 and Appendix C (OS), 10.6.0 for more 
information on coexistent program grouping. 
Note that this feature is not functional on 
1130 PLAN. 


The following example illustrates a portion 
of a program a user might write to estab- 
lish the first of the above special charac- 
ters (*) as a program name in the pop-up 
load list. 


DIMENSION A(2) 

DATA A/* * *, *bbbb*/ 
@ 

e 

e 


CALL LIST(2,A) 


"LIST" is called to move the contents of 
the double-word array to the pop-up list. 


The following is a summary of the require- 
ments for program list construction: 
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1. A program name must begin with an 


alphabetic character. Subsequent 
characters in the name may be either 
alphabetic or numeric. No special 


characters are allowed within a program 
name. A program name may be as long as 
eight characters for System/360 PLAN 
users and as long as five characters 
for 1130 PLAN users. 


2. The three EBCDIC characters << 
asterisk, left parenthesis, and right 
parenthesis -- are exceptions to the 
rules stated above. These three 
characters are considered valid program 
names. 


3. The asterisks, left parenthesis, and 
right parenthesis need not be 
delineated with commas. 

4. Unmatched right parentheses may be 


included. 


5. Consecutive commas indicate that the 
program items to the left in this list 
are to replace all items currently in 
the list. For example "PRO ‘'A,B,,‘" 
will eliminate all list entries and 
place A and B into the list. 


The following example illustrates an ADD 
PHRASE with a valid program list and shows 
the contents of the pop-up list after the 
command NAME is executed. 


ADD PHRASE: NAME, PRO‘'A,B* (D,E,F),,‘..-?3 


—--} cr 


o@wme} On #0 Pe 


t 
| 
1 
[ 
I 
| 
| 
I 
[ 
z | 


The consecutive commas in the program list 
cause the program names contained within 
the quote marks to completely replace 
existing program names in the pop-up list. 
In the example above, program A is executed 
first, and its name is removed from the 
pop~up list. After A is executed, B is 
loaded into core and executed. Suppose 
that during B's execution a checkpoint is 
taken, (B is saved on disk) and two new 
programs, X and Y, are placed at the top of 
the pop-up load list. 
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Since xX is at the top of the pop-up list, 


it is loaded into core and executed, and 
its name is removed from the pop-up list. 
Yis then similarly treated. The next 
program name in the pop-up list is *. This 
special program name causes a return to a 
checkpointed program. Bis reloaded into 
core and B‘s' execution continues at the 
next executable instruction. after the 
checkpoint instructions. The * is removed 
from the pop-up list. When B is completed, 
the left parenthesis "(" is encountered in 
the pop-up load list. This special program 
name signals PLAN that the subsequent pro- 
gram names, until a right parenthesis ")" 
is encountered in the pop-up list, are to 
be simultaneously core-resident. PLAN will 
load D, E, and F into core and remove their 
names and the left parenthesis "%(" and 
right parenthesis “)" from the pop-up list. 
When D, E, and F have’ concluded their 
processing, a zero will be encountered in 
the pop-up list. This indicates that the 
pop-up list is empty and that PLAN must 
load PSCAN to read the next command and 
analyze it. 


4.3.5 VERB DESIGNATION AND PROGRAM LIST 


The specification word VERB is used to 
define a phrase that is not a complete 
command. The VERB phrase is used to change 
or modify the meaning of an OBJECT (non- 
verb) phrase. 


A VERB phrase may have two types of program 
lists. One is associated with the keyword 
VERB and the other with the keyword PRO- 
GRAM, They will subsequently be referred 
to as VERB lists and PROGRAM lists. 


A command may consist of only one OBJECT 
phrase but may contain up to eight. VERB 
phrases as prefixes to the OBJECT phrase 
providing a maximum of 45 words in a 
command (a phrase is 1-5 words). (See 
"PLAN Language Terminology" 4.1.0.) A 
DELETE PHRASE of a VERB phrase must contain 
the specification word VERB. 


The pop-up list at the end of processing a 
command containing VERB phrases will con- 
tain (listed in top-to-bottom order) pro- 
gram lists defined in the phrases in the 
order listed below: 
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r— 


Check entry programs from leftmost| 


VERB phrase (#C'LIST', 4.3.15) | 


list from leftmost VERB 
phrase (PROGRAM‘A,B,C',4.3.4) 


Program 


Check entry programs from rightmost 
VERB phrase (#C'LIST', 4.3.15) 


| 
| 
| 
| 
] 
| 
| 
| 
| 
| 
| 
| 
Program list from rightmost VERB| 
phrase (PROGRAM‘A,B,C*,4.3.4) | 


phrase (#C'LIST',4.3.15) 


Program list from OBJECT phrase 
(PROGRAM‘'A, B,C", 4.3.4) 
Verb designated program list from 
rightmost verb phrase (VERB‘A,B,C"', 
4. 3. 5) 


Verb program list from leftmost VERB 
phrase (VERB'A,B,C',4.3.5) 
Existing program list (in the case 
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| 
| 
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| 
| 
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| | 
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| 
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{ 
{ 
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| 
| 
| 
| 
| 
! 
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The following example illustrates defini- 
tion of an OBJECT phrase and a VERB phrase. 
The phrases are then used as a command and 
the resultant program list is shown: 


(OBJECT PHRASE) 


ADD PHRASE: DATA, 
PROGRAMS ‘PROGB‘; 


(5)A-*R*PROGA', +, 


(VERB PHRASE) 


ADD PHRASE: EXPLAIN, (5)A, B, (255)* 
T*PROGC', VERB‘ PROGD', PROGRAMS‘ PROGES ; 


(COMMAND) 
EXPLAIN DATA, A, B95; 


The resultant pop-up list contains the 
following programs: 
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|PROGC] (in list only if communication 
| ] array (255) is not TRUE) 

| | 

| PROGE| 

| | 

|PROGA| (in list because data was not 
| | given for A) 

| I 

| PROGB| 

I 1 

| PROGD| 

Sane | 


Additional information on the sequence of 
execution is given under "PSCAN Execution 
Sequence", 4.3.25. 


The following example illustrates use of a 
VERB phrase to modify standard data for an 
OBJECT phrase. Assume an OBJECT phrase 
(MOTOR VEHICLE DATA) is designed to intro- 
duce data for a series of motor vehicle 
calculations. One of the data items is the 
minimum driving age (MDA). The country- 
wide standard is set at 16. Assume the 
standard for New York to be 18. A VERB 
phrase (NEW YORK) is defined to modify 
MOTOR VEHICLE DATA to a minimum driving age 
of 18. Obviously, this simple example 
could be extended across many data items 
with many modification options. Example: 


ADD PHRASE: MOTOR VEHICLE DATA, 1(1) 
MDA16, PROG*MVCAL‘,...; 


ADD PHRASE: 
I(1)MDA18, ...; 


NEW YORK, VERB, 


If the command “NEW YORK MOTOR VEHICLE 
DATA;" is executed, the minimum driving age 
(18) for New York would override the 
country-wide standard (16) and be used in 
the motor vehicle calculations by the pro- 
gram *‘MVCAL‘. 


Phrase defined data as defined in the 
following sections is written in the fol- 
lowing format: 


C~TO TATA TA T-T-T-1 

[UJ T(PISINIVIE[X| 

Lid dott LoL d 

U is the user-exit specification (4.3.18) 

I is the mode indicator (4.3.14) a 

P is the scale factor (4.3.13) 

S is the communication array position 
(4.3.6 peas 4.3.10) 
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N is the data name (4.3.11) 
V is the default value (4.3.12) 


E is the checking (check entry) specifica- 
tion (4.3.15) 


X are the expressions to evaluate (4.3.16 


4.3.6 COMMUNICATION ARRAY POSITION 


Definition of a data item is not complete 
unless it includes a definition of where 


the data item is to be stored. Data items 
are stored in a COMMON array known as_ the 
“communication array" (see "General 


A single 32-bit word 
within this array is referred to asa 
“communication array position" (CAP). The 
definition of a CAP is required to provide 
communication between the input processor 
(PSCAN) and the system analyst (and pro- 
grammer). Since the CAP definition repre- 
sents a displacement relative to the begin- 
ning of the communication array, the term 
subscript is sometimes used interchangeab- 
lywith the term CAP. However, in the 
strictest sense, these terms are different 
from each other. 


Description" 2.0.0). 


The CAP may be defined in any of four 
different ways. It may be defined as a 
CONSTANT, an IMPLIED DO, an ARITHMETIC 
OPERAND or the combination of an ARITHMETIC 
OPERAND and an IMPLIED DO. 


4.3.7 CAP DEFINED AS A CONSTANT 


A CAP defined as a constant takes the form 
(n), where nis an integer constant in the 
range 1 to 16,368. The CAP has a limit of 


8176 if a data name is associated with the 
CAP. For example, (33) specifies that the 
33rd word in the communication array is 


desired, for some purpose, for an asso- 
ciated data item. The reader will recall 
that the System Switch words immediately 
precede the communication array. It is 
possible, by defining a CAP as a negative 
integer constant in the range -1 to -15, to 
reference those COMMON switch indicators 


(see "Switch Words", 4.3.22). 

32-BIT 

WORDS 

rr Ciena | rien cee eee aaa aaa a] 
I | I | r | ff { 
| | pee [| bk Ter J | 

{ { i of rf t t | | 

tL... 4 a Se en | a J 
(-1) (-2) (-15) (1) (2) (16,368) 


System Switch Words Communication Array 
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4.3.8 CAP DEFINED AS AN IMPLIED DO 


The definition of a CAP may designate a 
range within the communication array. A 
range plus an increment within the range is 
indicated in a manner similar to the FOR- 
TRAN DO LOOP. The following example illus- 
trates a CAP defined as an Implied Do. 
Reference to the communication array starts 
at position 17, with subsequent references 
at every third word (20, 23, 26...), ending 
at position 38. 


(17,38,3) 


The general form of the CAP defined as an 
implied DO is (I,, Ia, I3), where: 


I, is the first referenced communica- 
tion array position, 

Iz is the last referenced communication 
array position, and 

Iz is the increment used to reference 
subsequent CAPs within the range 
specified by I, and I2. 


Three rules must not be violated when 
defining a CAP as an Implied Do: 


(1) Iz must not be negative. 

(2) The range divided. by the 
must equal a whole number. 

(3) A single-valued logical or numeric 
constant (nuv,+t,-) must follow 
definition of a CAP defined as an 
implied DO. 


increment 


Failure to comply with these three rules 
will cause a PLAN system diagnostic to be 
issued, and the phrase in question will not 
be added to the dictionary (PFILE). The 
reader may wish to verify that our example 
(17, 38, 3) does not violate our three 
rules, and as such is acceptable as a CAP 
defined as an Implied Do. Since I, and Ig, 
represent displacements relative to the 
same core location (the beginning of the 
communication array), the range can be 
determined by merely subtracting I, from 
Ia. Hence, the range in the above example 
is 21. The range (21) divided by the 
increment (3) results in a whole number 
(7). Thus, rule (2) is satisfied. Rule 
(1) is satisfied by inspection. 


Although Ig may not be negative, a negative 
integer is allowed for I,. Defining I, as 
a negative integer gives the user the 
ability to reference the System Switch 
Words as part of the range of the Implied 
Do. An example of a valid CAP definition 
which references the System Switch Words 
and functions as an Implied Do is (-1,22, 
3). However, since I, and Ig are not 
relative to the same core location, a 
Slight problem arises in determining the 
range of the Do. This problem is resolved 
by adding 15 to Ig, thus making Ig relative 
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to the beginning of the System Switch 
Words. I, is then treated as a positive 
integer. Since (-1) really means Switch 
Word 1, testing I, as a positive integer 
causes I, to become relative to the begin- 
ning of the System Switch Words. The 
reader should verify that the range in the 
example (-1,22,3) is 36. 


One last point worth noting about defining 
a CAP as an Implied Do is that I, (the 
increment) may be omitted. If such is the 
case, the increment is assumed to be 1. In 
the example (3,27) the first referenced CAP 
is 3, subsequent references are 4, 5, 6, 7, 
etc., through the last referenced CAP, 27. 


4.3.9 CAP DEFINED AS AN ARITHMETIC OPERAND 


A CAP may be defined as an Arithmetic 
Operand. Arithmetic Operands, as described 
under “PLAN Language Terminology", are com-— 
posed of data names and constants connected 
by the operators *, /, + and -. An example 
of a CAP defined as an Arithmetic Operand 
is (M + 2- N). The discussion on “Data 
Names", 4.3.11, states that a CAP defined 
as an Arithmetic Operand (symbolic CAP) 
requires an associated data name. Since 
the effective value (the actual displace- 
ment from the beginning of the communica- 
tion array) of a symbolic CAP is not 
determined until execution of the phrase 
which contains the symbolic CAP, and since 
all data items require an associated core 
storage location, the data name becomes the 
“handle* by which the data item is known. 
Thus, our example as given is not complete 
and must be rewritten to read, for example, 
(M + 2 - NYABC. It is important to note 
that M and N are previously defined data 
names with associated positions in the 
communication array. 


Suppose the two commands listed below were 
executed in the order shown. 


(1) ADD PHRASE: 
I(5)M, I(6)N, 


SYMBOLIC CAP EXAMPLE, 
(M+2-N) ABC-; 


(2) SYMBOLIC CAP EXAMPLE, M30, N25; 


Execution of command (1) places the phrase 
"SYMBOLIC CAP EXAMPLE" into the language 
dictionary (PFILE). This phrase specifies 
that CAPs 5 and 6, known as M andwvN 
respectively, should contain integer values 
and that the symbolic CAP (M+2-N), known as 
ABC, should contain logical FALSE (if no 
override is specified) as the initializa- 
tion value. Execution of command (2) first 
causes the values 30 and 25 to be stored as 
integers in CAPs 5 and 6. Then the symbol- 
ic CAP (M+2-N) is evaluated. The expres- 
sion is evaluated using the current con- 
tents of the CAPs specified by the symbols 
within the expression. Thus, the symbolic 


‘required. 
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CAP in this case is evaluated as (30+2-25). 
Since no override was specified in command 
(2) for ABC, CAP 7 will be set to logical 
FALSE. 


It is possible to direct the PLAN system to 
evaluate a symbolic CAP by using the actual 


displacements of the data names in the 
expression rather than their associated 
contents. This method of evaluation is 


specified by prefixing the data names 
involved with S*. If in command (1) above 
we had written (S'M+2-S'N)ABC- instead of 
(M+2-N)ABC-, regardless of the values spec- 
ified for M and N by command (2), CAP 1, 
known as ABC, would be set to logical 
FALSE. The symbolic CAP (S*M+t2-S‘'N) is 
evaluated using the CAPs (or displacements) 
of M and N, which are, respectively, 5 and 
6. Thus, the symbolic CAP in this case is 
evaluated as (5+2-6). It is important to 
note that as a phrase is being processed, 
gata names are added to the symbol table 
(see "PLAN Language Use", 4.2.3) from left- 


‘to-right and the execution-defined symbolic 


CAPs are evaluated in sequence. This means 
that the identity of a data name may change 
during symbol table creation. Example: 


ADD PHRASE: 
(S'A)C, (14)A; 


TEST, (1)A, (S'A+2)A, 


would yield the following symbol table: 


(3)c, (14)A 

CAPs defined as Arithmetic Operands at 
language definition time (ADD PHRASE) must 
result in an effective value of less than 
512 if a scale factor is defined; other- 
wise, less than 8,176. 


Note: All defined limits (such as less than 


512, less than 8176) will be more 
clearly understood by study of the 
organization of the Phrase Entry 


Table in Appendix E, 12.1.4. 


4.3.10 CAP DEFINED AS AN ARITHMETIC OPERAND 
AND AN IMPLIED DO 


An example of a CAP defined as the combina- 
tion of an Arithmetic Operand and an 
Implied Do is (M+2,10,2)NAME1. As in the 
case of a symbolic CAP, a data name is 
In this example, the data name 
is NAME. The above example is evaluated in 
the: following manner: 


1. The first parameter, I,, is evaluated 
at execution time by obtaining the 
current contents of the data name M and 
adding the constant 2 to that value. 
The result of the evaluation specifies 
a CAP which will be known as NAME and 
will be the first referenced CAP of the 
Implied Do. ; 
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2. The second parameter, Isa, is a 
displacement from the result obtained 
by evaluating a When this 


displacement is added to that result, 
the last CAP to be referenced by the 
Implied Do becomes known. 


3. Is3 is the increment. 


Note that Iz, must be 


constants. 


and I3 integer 


Assume that the current content of the CAP 
known as M is 30. Then I, would be 
evaluated as 32 and Iz would become 42. 
Since in our example, I3 is 2 and a default 
value of 1 is defined for the Implied Do, 
CAPs 32, 34, 36, 38, 40, and 42 would be 
initialized with the value 1. Since a CAP 
defined as the combination of an Arithmetic 
Operand and an Implied Do reduces to an 
Implied Do (at execution time), it is not 
possible for PLAN to determine the range at 
ADD PHRASE time. To ensure that the rule, 
range divided by increment must equal a 
whole number, is not violated, the user 
must define Iz and Iz as constants, where 
Iz is an integer multiple of I3. 


4.3.11 DATA NAME 


The data name allows the definition of data 
to be processed with the phrase in terms 
familiar to the problem definer. For 
example, suppose the problem definer were 
interested in calculating the electromotive 
force or voltage across a wire of given 
resistance at varying currents, he could 
define the data names as V, I, and R, where 
V=tI1Ix R (Ohm's Law). However, if the 
data names chosen were VOLTS, CURRENT, and 
RESISTANCE, the data items these names 
represent might perhaps become more 
meaningful to the problem definer. A 
Single data name may be associated with 
only a communication array position 
(hereafter identified as CAP) or a Switch 
Word. Remember, the term “communication 
array" refers to both the managed and 
nonmanaged data arrays, and the texm 
"Switch Word" refers to one of 15 32-bit 
words that comprise the System Switch 
Words. A data name must be present if a 
symbolic CAP is used (see “Communication 
Array Position", 4.3.6). A data name may 
be changed at any time by the user to one 
more meaningful to him without causing a 
change to the problem-oriented logic 
modules. If a data name change is desired, 
the user must consult the system analyst so 


that the system analyst may reflect the 
data name change ina dictionary (PFILE). 
Data names as defined in the preceding 


definitions follow the restrictions listed 


below: 
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1. A data name must be one WORD (a 
sequence of one or more alphabetic 
characters with no embedded blanks). 


2. A data 
letter E. 


name must not be the single 


3. A data name must not contain numerics 


or special characters. 


4. Since PLAN truncates WORDS to three 
characters or pads out WORDS with 
blanks to three characters, care must 
be taken when choosing data names to 
ensure that duplication of data names 
does not occur within the same phrase. 


5. The data name must immediately follow 
the definition of the CAP. 


The following example illustrates defini- 
tion of the data element with the data name 
VALUE (effective PLAN data name VAL) to be 
associated with CAP 33. This means’ that 
when the data name VALUE is encountered in 
a problem description stream, any data 
associated with it will be stored in posi- 
tion 33 of the communication array. 


(33) VALUE 


4.3.12 DEFAULT VALUES 


A default value, defined in a phrase is a 
value that is used to initialize an asso- 
ciated CAP when that phrase in PFILE is 
executed. The default value may be a 
literal, a logical constant, or a numeric 
constant, and must immediately follow the 
data name. If a data name is not defined, 
the default value must immediately follow 
the CAP definition. For a review of a 
literal, a logical constant, and a numeric 
constant, see "PLAN Language Terminology", 
4.1.0. The following two commands cause 
the phrases A and B, which specify dif- 
ferent default values for the same CAP, to 
be entered into the language dictionary 
(PFILE) : 


ADD PHRASE: A,(20)“ABC"; 


ADD PHRASE: B, (20) VALUE70; 


Suppose now, after the two commands above 


have been executed, the three commands 
listed below are executed in the order 
shown. 

(1) A; 

(2) Bs; 


(3) B,VALUE-; 


Execution of the command in step (1) would 
cause CAP 20 to be initialized with the 
default value “‘ABC" (core representation 
ABCb) . Execution of the command in step 
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(2) would cause CAP 20, known as VALUE, to 
be initialized with the default value 70. 
Execution of the command in step (3) would 
cause CAP 20, known as VALUE, to be set to 
logical FALSE. Step (3) is an example of 
how the problem definer may override a 
default value. Steps (1) and (2) illus- 
trate that PLAN supplies the standard data 
value (default value) whenever commands 
fail to specify an override. Of course, if 
no default value was defined for a CAP at 
ADD PHRASE time, and no value is specified 
for the CAP at phrase execution time, PLAN 
would have nothing to supply as the stand- 
ard data value. In that case, the CAP 
would contain residual data stored from the 
previous command in the input stream. The 
“default value" option should prove useful 
to the PLAN user aS a means of reducing 
execution-time problem definition. 


4.3.13 SCALE FACTORS 


Input data may be scaled by a specified 
power of 10 in the range of plus/minus 7. 
Scaling is indicated by a Ptn indicator, 


where nis in the range of 1-7. A plus 
sign indicates movement of the decimal 
point to the right; a minus sign indicates 


movement to the left. The scaling indica- 
tor must immediately precede the CAP indi- 
cator. In the following example, the value 
associated with the identification VALUE is 
to be scaled from feet to hundreds of feet. 
The value is’ stored in the communication 
array position 33. A default (initializa- 
tion) value of five defines a standard data 
value of 500. Scale factors may not be 
used with CAP indicators that reference the 
System Switch Words, that is, CAPs’ that 
have negative subscript indicators. Scal- 
ing will be provided to either the default 
value or the given data value. Example: 


P+2(33) VALUE 5 


4.3.14 MODE 


The normal storage mode of PLAN is real 
(floating-point). Literal data automati- 
cally overrides this standard. The user 
may designate integer (fixed-point) storage 
mode by prefixing an I to the scale factor, 
or to the CAP if no scale factor exists. 


In the following example, a fixed-point 5 
is associated as a standard value with 


sequence of operations when a scale 
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communication area 33, and is assigned the 


data name VALUE. Example: 
I (33) VALUES 
The following example illustrates the 


factor 
and mode are defined. Example: 
IP+2(20)NAME4.1 is interpreted in the 
following manner: 

e Scale by a factor of 100 (410.<4.1) 

e Integer conversion (410<-410.) 

e Communication array (20)=410 


4.3.15 CHECKING RULES 


Checking of values in the communication 
array may be achieved during command proc- 
essing (PSCAN execution) immediately before 
transfer to PLAN for the loading and execu- 
tion of the first problem program module. 
The rules to be followed in performing the 
checks at command processing (problem- 
solution) time are defined in the phrase 
and are known as a check entry. 


A check entry contains the following two 
parts: 


(1) Definition of a test to be performed 
(2) Definition of an action to be taken if 
the test fails 


The definition of the check entry is writ- 
ten in the relative location within an 
element‘s description normally used for the 
standard data value, or it immediately 
follows the standard data value. The 
result of the test may be used to terminate 
processing of the command, to alter the 
sequence of programs to be executed, or to 
generate a diagnostic message. The general 
form of a check entry definition is: 


(N) TEST ACTION 


The N is the CAP (in the range of -15 to 
+8176). TEST indicates the condition to be 
tested, and ACTION controls the action to 
be taken if the defined test fails. If the 
defined test passes, the ACTION is ignored. 
The conditions that can be tested and the 
ACTIONS that may be specified are shown in 
Figure 6. 
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{ ACTION | 
eater nner tnd 
| TEST jNone|' LIsT'{c* DIAG" |A'DIAG"|P'PHRAS' | (N)|C(N) JAG) ]P(N) | 
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*NOTE: See Figure 7 for an explanation of the numbers in this figure. 


Figure 6. Summary of check entry processing 
ee 
| CODE |SYSTEM ACTION TAKEN | 
[ann nan nnn nnn { 
{ 1 {Abort the command. PLAN level | 
| jerror recovery is initiated. | 
| 1 
{ 2 [Last pushed command is the only | 
| {command executed. | 
( { | 
{| 3 |The processing of the current | 
| {command is continued. | 
| | | 
1 4 | PLAN diagnostic 223-226 is | 
| |[generated. | 
| | 
| 5 |The user diagnostic "DIAG" is | 
| {generated. | 
{ | 
{ 6 {The program list defined by LIST | 
{ {is added to the pop-up list. | 
I | 
{ 7 {The command “PHRAS" is executed | 
| [mext. The pop-up list is not | 
| |modified. | 
| | 
{| 8 {The user diagnostic contained in | 
| [PLAN literal form at position "n" | 
| Jof the communication array is | 
| | generated. | 
| | | 
| 9 |The program list located at | 
| jposition “"n" of the communication | 
| jarray is added to the pop-up | 
| jlist. | 
| | 
{ 10 |The command existing in PLAN lit- | 
{ jeral form at position “n" of the | 
| {communication array is executed | 
| Jnext. The pop-up list is not | 
| |modified. { 
L ta J 
Figure 7. Summary of check entry actions 


Actions are controlled by the phrase con- 
text text (ACTION) that follows the condi- 
tion TEST. For example, check entry 
*TC"DIAG' specifies a test for TRUE (*T) 
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where action is to be taken according to 
the ACTION (C'DIAG') if the value tested is 
FALSE or REAL. The system action taken is 
specified by the two numbers indicated by 


the coordinates *T and C‘'DIAG’, in this 
case 3 and 95. The numerical codes in 
Figure 6 are defined in Figure 7. Note: 
Logical TRUE in hexadecimal is 80000000. 


Logical FALSE in hexadecimal is 7FFFFFFF. 
Any other value is REAL. 


The ACTIONS that may be defined are 
described below. The codes shown in Figure 
6 that correspond to these actions are 
indicated within parentheses following each 
action heading. 


Abort Phrase (None) 

If, when the tested condition is not 
met, this phrase and following phrases 
are to be skipped until a phrase of 
equal or higher level is encountered 
(see “LEVEL"), no action indicator is 
required. A PLAN diagnostic logs the 
check entry failure and shows the word 
that was tested when the test failed 
(see execution error codes 223-226 in 
Appendix F, 13.0.0). 


Modify Pop-up List ("LIST* or (N)) 
A string of program names may be added 


to the pop-up list if the tested condi- 
tion is not met. The program names are 


included as a literal string, for 
example, ‘M1111, M2222, M3333‘. This 
literal string corresponds to the 


option ‘LIST'. An alternate method for 
adding program names to the pop-up list 
makes use of the option (N). The 
option (N) is the subscript of the 
communication array location that con- 
tains the count of the number of words 
in the adjacent list. The program. list 
in the communication array must” be in 
EBCDIC representation. Each program 
name must occupy two PLAN words. The 
CAP position referenced by the check 
entry, for example, *T(10), may have 
been established with the following ADD 
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PHRASE entry. The list must be pre- 
ceded with the integer count of the 
number of PLAN words to be added to the 
list. Example: 

1(10)4, "PROGA", “PROGB"... 

PLAN error recovery is not initiated. 
Additional information on the formation 
of program lists is given under “Pro- 
gram List". If any errors are found in 
the command or if the command is to be 
skipped as a result of level error 
recovery procedures, the programs will 
not be executed. 


Use of the option to modify the pop-up 
list is a technique often used to call 
an error module if the expected amount 
of data is not given by the user. Data 
tests give either the results TRUE or 
FALSE, based on the logical value of 
the data word to be tested. If the 
result of the test is TRUE, the action 
option is not performed. If the result 
of the test is FALSE, the action indi- 
cated by the option is executed. An 
example of how this technique may be 
implemented follows: 

ADD PHRASE: DATA, (5) A-**PROGA‘... 7 
The check entry *"‘PROGA' tests CAP 5 
for NOT FALSE. The test will fail if 
CAP 5 contains FALSE. Since a default 
value of FALSE is specified for CAP 5, 
the test will fail for all instances 
where no data is submitted to override 
the default value. If no data is 
submitted (the test fails), PROGA is 
added to the pop-up list and executed. 
It is assumed that PROGA is an error 
module. 


The program added to the pop-up list, 
as a result of check entry. action, is 
placed in the list after programs in 
the phrase program list (see “Program 
List", 4.3.4), and will therefore be 
executed first. If no action entry is 
specified (abort option), PLAN 
generates an error diagnostic for any 
FALSE result and returns, after all 
tests have been performed, to PSCAN for 
processing the next phrase. 


Generate Diagnostic and Abort Phrase 


(A*DIAG' or A(N)) 

PLAN level error recovery is initiated 
following generation of a diagnostic 
when the condition is not met. The 


action indicator is either the constant 
subscript (A(N) option) of a location 
within the communication array that 
contains the count for the adjacent 
literal, or the literal itself 
(A‘DIAG'). PLAN error recovery proce- 
dures are initiated to skip all phrases 


The 
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until a phrase of equal or higher level 
is encountered (see “Level of Phrase", 
4.3.3"). 


Generate Diagnostic and Continue Phrase 
(C* DIAG" or C(N)) 


The execution of the current phrase is 
continued following generation of a 
diagnostic (A PLAN literal or the con- 
stant subscript of a location within 
the communication array that contains 
the literal) when the condition is not 
met. 
Invoke Execution of a_ New Command 
(P*PHRAS* or P(N)) 

The new command is scheduled for execu- 
tion. The command image is given as a 
PLAN literal, or as the subscript of 
the communication array location con- 
taining the literal. The terminating 
semicolon is not included in the liter- 
al, but a blank must be provided to 
allow its insertion. This action must 
not be used in a command that is to be 
implicitly saved (see “Statement Save", 
4.3.22). More than one command may be 
"pushed" from a check entry because the 
scan of the command is continued. 
However, Only the last one "pushed" 
(the rightmost check entry in the left- 
most verb) will be executed. If any 
abort message is produced by the cur- 
rent command or if the current command 
is to be skipped as a part of level 
error recovery processing, the “pushed" 
command will not be executed. 


following examples illustrate the use 


of check entries. 


1. 


(2)* writes a PLAN error message and 
aborts the phrase if the value of (2) 
is FALSE. *, the test for NOT FALSE, 
fails on FALSE only. 


(2)*T writes a PLAN error message and 
aborts the phrase if the value of (2) 
is NOT TRUE. *T, the test for TRUE, 
fails on FALSE or REAL (NOT TRUE). 


'(2)*F writes a PLAN error message and 


aborts the phrase if the value of (2) 
is NOT FALSE. *F, the test for FALSE, 
fails on TRUE or REAL (NOT FALSE). 


(2)*R writes a PLAN error message and 
aborts the phrase if the value of (2) 
is not REAL. *R, the test for REAL, 
fails on TRUE or FALSE (NOT REAL). 


(2) *°P222,P345,P98,P35' inserts the 
program names P222, P345, P98 and P35 
into the pop-up list, if the value of 
(2) is FALSE (NOT TRUE or _ REAL). 
Consecutive commas within the list eli- 


Minate all currently existing names 
from the pop-up Jist (see “Program 
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10. 


11. 


12. 


46 


List", 4.3.4). Processing of the cur- 
rent phrase continues. 


(2) *A*DATA VALUE MISSING" writes a 
diagnostic, DATA VALUE MISSING, and 
aborts the phrase if the value of (2) 
is FALSE. 


(2)#C*ONE INCH RADIUS ASSUMED‘ writes a 
diagnostic, “ONE INCH RADIUS ASSUMED", 
and continues processing if the value 
of (2) is FALSE. 


(2)*P"DUMP * invokes execution of the 
command DUMP if the contents of (2) are 
found to be FALSE. The scan of the 
current command is continued. Note 
that implicit saving of statements is 
inhibited by failure of this test. 


(2)*(30) If the test fails, add the 
program list whose length is contained 
in CAP 30 to the pop-up list, and 
continue processing the current phrase. 
The data at location 30 must be in the 
following general form: 
n, “NAME1", “NAME2", ... 
where: n is the number of PLAN 
(32-bit) words that follow 
and must be added to the 
pop-up list. A value of 2 
times the number of program 
names must be specified for 
n. 


NAME1,... iS a program name 
to be added to the pop-up 
list and must be given in 
two 32-bit words and must 
include trailing blanks. 


Note that the format of the array 
to be processed is identical to 
that required for processing by the 
PLAN loader subroutines (see CALL 
LIST/LEX/LOCAL/LREPT under "Program 
Linkage Routines", 5.11.1). 


(2)*#C(30) If the test fails, write a 
diagnostic and continue processing. 
CAP 30 contains the character count of 
the PLAN literal that is to make up the 
diagnostic text. 


(2)*#A(30) If the test fails, write a 
diagnostic and abort the phrase. CAP 
30 contains the character count of the 
PLAN literal that is to make up the 
diagnostic text. 


(2)*P(30) If the test fails, invoke 
execution of the command that is found 
in literal form minus the semicolon at 
CAP 31. The character count is found 
at location 30. The literal count must 
include a blank at the end of the text 
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to allow for insertion of the semico- 
lon. Note that implicit saving of 
statements is inhibited by failure of 
this test. 


A phrase may be continued automatically by 
forcing the last check entry in a command 
to fail and thus invoke execution of the 
phrase continuation. Example: 


ADD PHRASE: NAME,...(1)-*TP‘CON NAME '; 


ADD PHRASE: CON NAME, ...; 
Using this method, the formula area (see 
"Formula Area", 4.3.20) may not be split 


between commands if backward branching is 
required. Neither will data generated by 
the CONTINUE command be tested by check 
entries in the first command. Pop-up list 
(program) entries effected by the first 
command remain and will be executed follow- 
ing entries placed in the list by the 
CONTINUE command. 


Combinations of logical expressions (see 
"Logical Operand", 4.1.11) and logical 
tests (see "Expressions", 4.1.12) may be 


used to change the implication of a phrase 
to suit the specific requirements of input 
data. The following example illustrates 
the use of checking to modify the program 
list for those cases where the value of 
ANGLE is less than .01. 


eee (2)ANGLE*R, (3) TEST 
*F*P204,,': (ANGLE<.01),... 


In the above example, ANGLE is the data 
name assigned to CAP 2. A check entry is 
specified to ascertain that a value for 
ANGLE is given (REAL, not FALSE, or not 
TRUE). TEST, assigned to CAP 3, is set to 
TRUE if the value of ANGLE is less than 
-01; otherwise, it is set to FALSE. If 


no further 
not FALSE, 


TEST is found to be FALSE, 
action follows. If TEST is 
program name P204 is added to the pop-up 
list. The consecutive commas indicate that 
existing names in the pop-up list are to be 
eliminated. 


4.3.16 EXPRESSIONS TO EVALUATE 


Arithmetic and logical expressions may be 
defined to generate data values as arith- 
metic or logical results of other data 
values. Arithmetic expressions are intro- 
duced with the equal sign; logical expres- 
Sions are introduced with a colon. In the 
examples of valid expressions given below, 
included blanks are optional: 


A=A*.017453, 
=B+*100, 

B:(A>5) & (A<10), 
(5) : B& CI4D, 
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Warning: If a data _ name for a CAP, which 
contains logical TRUE or FALSE, appears in 


an arithmetic expression, the resultant 
evaluation of the arithmetic expression 
will be logical FALSE. Assume the CAPs 
known as B, C, and D contain the values 4, 
+(TRUE) and 3.3, respectively. In the 
example, (1) A=B*C-D, CAP (1), known as A, 
would be set to logical FALSE because C 


contains a logical value (logical TRUE). 


Standard data values (default values) and 
arithmetic or logical expressions may both 
be defined for a _ CAP. For example, (5) 
A-=A*. 0174532965, defines CAP 5 to be 


initialized as logical FALSE if no data is. 


submitted for A at execution time. Should 
data be submitted for A at execution time, 
the result of evaluating the arithmetic 
expression A*.0174532965 would be placed in 
CAP 5. The arithmetic expression above is 
one which converts degrees to radians. 


4.3.17 CONDITIONAL EVALUATION 


A data value may be conditionally generated 
on the basis of the evaluation of a logical 
expression. The arithmetic or logical 
expression which generates the data value, 
if the TRUE condition is found for the 
conditional logical expression, is preceded 
with a question mark (?). In the following 
example, NAME, defined for CAP 15, is set 
equal to AAA if the logical value of LLL is 
TRUE. 


Example: 


(15) NAME: LLL? = AAA, 


A second expression to generate a data 
value, preceded by an exclamation mark (!), 
may be defined for evaluation if the condi- 
tional logical expression, when evaluated, 
is found to be FALSE. The TRUE option must 
be present if the FALSE option is to be 
used. 


In the following example, DATA, assigned to 
CAP 5, is set equal to A multiplied by B, 
if it is TRUE that C is less than 50. If, 
however, C is not less than 50 (c> 50), the 
expression following the FALSE indicator 
(ft) is evaluated. This expression will 
set CAP 5 to logical TRUE if both D and F 


are TRUE. Otherwise, CAP 5 will be set to 
logical FALSE. 
Example: 
(S)DATA: (C<50)?=A*B !:D&F, 


The data names A, B, C, D, and F must be 
defined in the current symbol table. 
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4.3.18 USER-EXIT PROGRAMS 


User exits from PSCAN are provided to give 
additional conversion facilities of user- 
defined data. Examples of these could be 


feet to inches, extended precision, or 
fractional constants. Up to three dif- 
ferent user-exit routines may be defined 


for any given PLAN phrase. When a user 
exit is required in a phrase, those data 
items that require user-exit processing are 
specially indicated. 


When PSCAN encounters a data name that has 
an associated user-exit definition, the 
appropriate user-exit program will be 
called. Special subroutines are provided 
for scanning the input stream and placing 
the converted values in the PLAN communica- 
tion array. These subroutines are IUSER, 
NUSER, GUSER, and EUSER. They are dis- 
cussed later in this section. User-exit 
programs may not be used to store data into 
the Switch Words. All user-exit programs 
must terminate execution by a CALL EUSER. 
User-exit programs on the 1130 may not call 
LOCAL (see "PLAN Subroutine Use", 5.11.0)... 


During phrase definition time, standard 
phrase-defined data is written as follows: 


IPtn(CAP) data name 


Phrase-defined data that is to be processed 
by a user-exit program is written as 


follows: 


Um IPtn(CAP) data name 
U indicates that user-exit processing is 
required. The m represents one of three 
possible user-exit programs, associated 
with this phrase, to be executed and is 
expressed as 1, 2, or 3. Note that if 
user-exit programs are to be specified, the 
keyword EXIT may be used to specify the 
names of the three user-exit programs. If 
the keyword EXIT is not used, the standard 
default names EXIT1, EXIT2 and EXIT3 are 
automatically invoked (see "Exits", 
4.3.19). 


The definers I, P, and n are not available 
to the user-exit routine nor do they scale 
or alter format of the user-collected 
value. They are used by PSCAN when an 
expression is detected after a user-exit 
symbol. For instance, if the value asso- 
ciated with a user-exit symbol indicates 
the mode to be integer, and the data name 
is subsequently encountered in an expres- 
sion, the data value will be treated as 
integer for purposes of the evaluation. 


The user-exit program is entered during 
command scan time (PSCAN execution) when a 
data name with a user-exit definition is 
detected and the next significant character 
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does not indicate an expression or literals 
to follow. 


PSCAN will not relinquish control to the 
user-exit routine if the first recognizable 
nonblank character following the data name 
that is associated with the user exit is 
found to be an equal sign (=), a quote (‘), 
an at sign (@), a double quote ("), a pound 
Sign (#, BCD = sign), a colon (:), a comma 
(,), a left parenthesis ((), or a semicolon 
(:). 


PSCAN will not honor further calls to the 
character fetch routine (see "CALL GUSER") 
after a comma (,) or a semicolon (;) has 
been processed. Either of these characters 
results in the return of a binary zero by 
the fetch routine to the calling routine. 
The user should then return control to 
PSCAN with no further character fetch 
requests. 


It is the user's responsibility to index 
the communication array pointer when 
required. The user-exit program must alter 
the communication array pointer (see "CALL 
NUSER™ below) by an amount equal to the 
number of PLAN words (32-bit) stored. 


Four subroutine calls are provided for 
exclusive use within user-exit programs: 


CALL IUSER must be issued before any 
other user-exit program subroutine is 
called. It provides linkage to PSCAN and 
on 1130 PLAN sets index register 1 to the 
LIBF subroutine linkage block as defined 
in Appendix A, 8.0.0. 


CALL GUSER(ICHAR) accesses the next PSCAN 
input stream character and places it in 
ICHAR as an 8-bit EBCDIC character right- 
justified within the integer word ICHAR. 
The first CALL GUSER(ICHAR) issued fol- 
lowing each entry into a user-exit pro- 
gram is the first nonblank character 
following the data name that caused the 
user-exit program to be invoked. A zero 
is returned if a comma or semicolon is 
encountered. Further GUSER calls should 
not then be issued without relinquishing 
control to PSCAN (see “CALL EUSER" 
below). 


CALL NUSER(ISUB,ISW) places the current 


CAP in ISUB the first time it is called 
from each execution of a user-exit 
module. Isw is set to zero if it is 


permissible to store data values. If ISW 
is positive, the user-exit program must 
not store values in the communication 
array but must complete all other user- 
exit functions. The value will be posi- 
tive if the subscript specified is too 
large or if a user-exit program is pro- 
cessed while executing a “go to" in the 
formula area evaluation. The second and 
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each succeeding CALL NUSER issued during 
each execution of a user-exit program 
causes the CAP to be incremented by one. 
Thus NUSER should be called nti times if 
n 32-bit values are stored by a 
user-exit. 


CALL EUSER(N1,N2,LIT) returns control to 


PSCAN. User-exit programs must exit via 
this call. If N1 is zero, no error is 
indicated. If N1 is positive, the param- 
eters of this call are used as error 
parameters to call ERRAT. (See "PLAN 
Error Processing", 5.3.0.) 

The examples listed below show data that 


could be processed with user-exit program- 
ming. Examples: 


ADD PHRASE: NAME, U1(5)ABC...; 


1. NAME, ABC NODE FROM TO,...; 
2. NAME, ABC 7°4" 8°5%, 2.37 
3. NAME, ABC 7-4, 2-1, oes 


4. NAME, ABC LINE/DX4 DY7, ...3 

The data in example 3 could be degrees- 
minutes or anything else the user wishes. 
The hyphen is used merely as a_ delineator. 


Note that example 3 above results in two 
calls to the user-exit routine. The first 
call terminates (PSCAN returns a zero indi- 
cator and does not honor further calls to 
GUSER) when the first comma is encountered. 
The CAP points to ABC(1). When the comma 
is encountered, ICHAR is’ set to zero by 
CALL GUSER. CALL NUSER should then be 
called for the second time to increment CAP 
to the next value (ABC(2)). Then, since no 
data name is given for the next data item 
(2-1,), the same formatting rules (mode, 
user exit, scale factors) are used as for 
the preceding input value. (See "Data 
Value", 4.2.1.) A user-exit program is 
never entered unless the appropriate data 
name is encountered in the input command 
data stream. 


The following example would process. only 
one call to the user exit. The letter A 
following the comma would be interrogated 


as a DATA NAME: 
NAME, ABC A1B, A1C,... 
The command shown above has the following 


implications when executed by normal PLAN 
PSCAN processing. 


NAME VALUE 
A 1 

B TRUE 
A 1 

Cc TRUE 
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The statement scan may at times be required 
to pass over symbols and data that normally 
require user-exit conversion. This will 
happen during transfer of control over 
user-exit-associated data names when eval- 
uating execution-defined expressions. An 
indicator ISW (see "CALL NUSER") is zero if 
the user-exit program is to store values, 
and nonzero if values are not to be stored. 
In either case, the user-exit routine must 
CALL GUSER until a zero-value is returned 
in ICHAR, or an error may result from PSCAN 
causing a phrase abort. 


The following user-exit routine, written 
with 1130 FORTRAN control cards, illus- 
trates a FORTRAN user-exit program to. con- 
vert input in the form of feet-inches 
(3°11") into a value in inches. A_ portion 
Of the ADD PHRASE and execution-time phrase 
are also shown. 


ADD PHRASE: FOOT INCH, EXIT'EXIT1, FINCH, 
EXIT3", U2I(12)FIN,...; 

FOOT INCH, FIN 1'3", 12%3", 4°, 9", ...; 
// JOB 


47/7 DUP 
FINCH 


*LIST ALL 
COMMON L(625),LS(15) ,KA(510), PA( 2196) 


Cc SEE APPENDIX A FOR SPECIFICATION OF 
Cc PA (PROGRAM AREA PROTECTION) 
Cc INITIALIZE USER EXIT LINKAGE 
CALL IUSER 
Cc INITIALIZE SUM OF INCHES 
NSUM = 0 
NTEMP = 0 


c SET MODE SELECTION 
MODE = 0 
c IS STORE VALID 
CALL NUSER(ISUB, ISW) 
c FETCH CHARACTER 
1 CALL GUSER(ICHAR) 
c HAS SCAN BEEN TERMINATED 
IF (ICHAR) 25,25,5 
c IS IT SINGLE QUOTE 
5 IF (ICHAR ~125) 20,10,35 
c IS A SINGLE QUOTE ACCEPTABLE 
10 IF (MODE -1)15,30,30 
c CONVERT FEET TO INCHES 
15 NTEMP = NSUM * 12 


NSUM = 0 
Cc SET MODE SWITCH 
MODE = 2 
GO TO 1 
C INVALID CHARACTER INCREMENT SUBSCRIPT 


20 KERR = 101 ; 
22 CALL NUSER (ISUB, ISW) 
KCHAR = ICHAR 
Cc SCAN OUT TO END OF FIELD 
23 CALL GUSER (ICHAR) 
IF (ICHAR)24, 24,23 
Cc SET ERROR CODE - GIVE CHARACTER CODE 
24 CALL EUSER (KERR, KCHAR, 0) 
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INCREMENT SUBSCRIPT, STORE VALUE, AND 
EXIT 
25 IF(ISW)27,26,27 
26 KA (ISUB) = NSUM + NTEMP 
CALL NUSER (ISUB,ISW) 
27 CALL EUSER (0,0,0) 
Cc INVALID FORMAT - FOOT MARK INVALID 
30 KERR = 102 
GO TO 22 
Cc IS CHARACTER INCH INDICATOR 
35 IF (ICHAR=127) 20,40,60 
Cc IS INCH MARK VALID 
40 IF (MODE-2) 50,50,55 
Cc ERROR 103 
45 KERR = 103 
GO TO 22 
c SET OTHER CHARACTERS INVALID 
50 MODE = 3 
GO TO 1 
Cc INVALID CHARACTER FOLLOWING INCH MARK 
55 KERR = 104 
GO TO 22 
Cc IS CHARACTER ACCEPTABLE 
60 IF (MODE -3) 65,55,45 
Cc ACCUMULATE SUM IF NUMERIC 
65 IF (ICHAR -240) 20,75,70 
70 IF (ICHAR -249) 75,75,20 
75 NSUM = NSUM#10 + ICHAR-240 
GO TO 1 
END 
// DUP 
*STORECI 


an 


WS UA FINCH 


4.3.19 EXITS 


The keyword EXIT introduces a three name 
program list specifying the names of the 
modules to be executed as user-exit pro- 
grams 1, 2, and 3, respectively. The 
following example illustrates definition of 
PROGA for user exit 1, PROGB for user exit 
2 and PROGC for user exit 3. Example: 


EXIT ‘*PROGA, PROGB, PROGC',... 


If user-exit programs are specified for 
data item conversion and the keyword EXIT 
is not used to provide a routine name, the 
default program names EXIT1, EXIT2, and 
EXIT3 are used. 


The 1130 PLAN system provides a program 
named EXIT1 that converts data to extended 
precision. If the user were to program, 
compile, and catalog his two most common 
data conversion requirements under the 
names EXIT2 and EXIT3, the need to express 
the keyword EXIT and user-exit program 
names would be held to a minimun. 


4.3.20 FORMULA AREA 


When present, the formula area follows all 
other phrase-defined data and keyword 
entries (level, data items, program lists, 
etc.). The formula area iS aé_e special 
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adaptation of the function provided by 
formula numbers during language use time. 
The formula area is introduced with a 
dollar sign ($) and is terminated with the 
phrase-terminating semicolon (;). The for- 
mula area is comprised of any number of 
formulas within the limits of the maximum 
phrase length. Formulas are separated with 
commas. Each formula may be labeled with 
one or more formula numbers. A formula 
number is a dollar sign ($) followed by an 
integer number in the range of 0 to 1024. 
The formulas following a conditional eval- 
uation may be formula numbers that indicate 
the formula number to which control is to 
be transferred if the condition is satis- 


fied. They may also be expressions as 
defined under "Conditional Evaluation", 
4.3.17. Evaluation proceeds left-to-right 


Formula number 
in another 


within the formula area. 
zero may not be referenced 
formula. 


The differences between the ADD PHRASE 
formula area and execution-time formula 
number usage are outlined below: 


1. Allowable syntax organization 


a. ADD PHRASE: The formula area must 
be the last area in the defined 
phrase, that is, data item defini- 
tions must not follow the first 
occurrence of a formula number. 


b. Execution time: Data assignment 
not requiring expression evaluation 
(D57.5) may be intermixed with for- 
mula numbers and expressions as 
shown in the following example: 


EXECUTE, $5 A=B+C, D57.5, 
$2=B4C, eee ? 


F=(A/C), 


2. Unreferenced formula numbers 


a. ADD PHRASE: Unreferenced formula 
numbers are indicated by diagnos- 
tics (see Appendix F, 13.0.0). 

b. Execution time: Unreferenced for- 
mula numbers are not detected. 


3. Formula number limits 
a. ADD PHRASE: 1-1024 (Numbers greater 
than 1024 or equal to 0 are ignored 
but are invalid as references.) 
b. Execution time: 1-32, 767 


4. Valid expression number suffixes 
a. ADD PHRASE: Formula numbers must be 
followed by another formula number, 
by a data name, by an expression, 
or a comma or semicolon. 


b. Execution time: No restrictions. 
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5. Undefined formula numbers 


a. ADD PHRASE: Undefined formula num- 
bers are indicated by diagnostics 
(see Appendix F, 13.0.0). 


b. Execution time: Undefined formula 
numbers are not detected. A branch 
to an undefined formula number is 
treated like a branch to the semi- 


colon. A branch to formula number 
0 is not executed (acts like a 
NOP). 


The following types of statements may be in 
the ADD PHRASE formula area. Each may be 
prefixed with a formula number. The data 
name in each case is optional. 


1. Arithmetic evaluation 
data name = arithmetic expression, 
Example: A=B*100+C 


2. Logical evaluation 
data name: logical expression, 
Example: A:B|C&,D 


3. Conditional evaluation 


data name: logical expression ? = 
arithmetic expression or: logical 
expression !=arithmetic expression or: 


logical expression 
Example: A:(B<100) & (B>0)?=20!=0, 
X: (CA=—) & (B=+) ?sAEB! sA[B, 


4. Conditional branch 
data name: logical expression ?$n!5$m, 
Example: :(A>5) ?$3!5S4, 


5. Unconditional branch 
:$n, 
Example: :$3, 


6. Mixed conditional 


data name: logical expression ? 
expression !$n, 
data name: logical expression 
?$n!expression 


Examples: A: (B="ABCD") ?=1000 !$5, 
B: (A=+)?$1 !:BICc, 


Statements of the type defined in 4, 5, or 
6 above may result in transfer of control. 
A maximum of 1000 branches is permitted for 
the execution of any phrase. This prevents 
the programming of endless loops. 


The following example illustrates use of 
the formula area in the addition of a 
phrase. Reference should be made to “Log- 
ical Operand" and “Logical Expression" in 
the section “PLAN Language Terminology", 
4.1.0. The example produces the count of 
the number of literal values given at 


phrase execution time with the data name 
“NAMES". The number of literals will be 
accumulated at N (nonmanaged array 1), and 
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the CAP of the word following the last 
literal will be given at S. 


ADD PHRASE: TEST, I(-9)8192, M, I(M+1)NO, 
I(M+2)S1,  (M+3,97)NAMES~'"DEFAULT', $0: 
(NAMES (S)=+) 2$2!$4, $1N=N#1, S=S+ (NAMES (S) 
+7)/4-.5, $4:4NAMES(S) 2§2!$1, $2; 


The following explanation of the above 
example is treated step-by-step as executed 
at phrase-execution time: 


TEST, gives the name of the phrase _ to 
add to the language dictionary (TES) 
I(-9)8192, sets the size of COMMON to 
8192 words (Switch Word 9) 

M, sets the label M equivalent to 
Switch Word 10. It is assumed that 
Switch Word 10 is set at execution time 
by a level 0 command to the size of the 
managed array. 

I(M+1)NO, assigns the label N to the 
first position of the nonmanaged array 
and sets the default value for the 
location to zero. It is assumed that 
Switch Word 10, the size of the managed 


array, has been set by a previous 
phrase. 
I(M+#2)S1, assigns the label S to the 


second position of COMMON beyond the 
managed area and sets a default value 
of 1. 

(M+3, 97) NAMES-* DEFAULT’, sets the label 
NAMES equivalent to the third position 
of the nonmanaged array. The third to 
the hundredth position of the non- 
managed array is initialized to FALSE. 


The literal DEFAULT is set to the 
third, fourth, and fifth position of 
the nonmanaged array (see section "Mul- 
tiple Data Element Definitions", 
4.3.26). 

$0: (NAMES (S)=+) 2$2!$4, introduces the 


formula area ($0) and sets the number 
of the first formula to zero. If 
NAMES(S) is TRUE, transfer is to 
expression 2; otherwise, transfer is to 


4. This tests for the use of NAMES 
without a given literal. (Note that 
formula number zero may not be 


referenced. ) 
$1N=N+1, adds one to the counter (count 
of literals) that was initialized to 
zero, located in the first position of 
the nonmanaged area. 
S=S+ (NAMES (S)+7)/4-.5, calculates the 
position of the word that contains the 
next literal character count. 
4Us4NAMES(S)?52!51, causes a transfer 
to formula 2 if NAMES(S) is FALSE; 
otherwise, transfer is to formula 1. 
$2; indicates the end of processing. 


Check entries defined in a phrase are 
evaluated following execution of phrase 
defined formulas. Thus, check entries may 
be used to test for the validity of tests 
performed within the formula area. 
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4.3.21 SWITCH WORDS 


A block of 15 switches is a portion of the 
standard PLAN permanent residence section. 


The 15 switches are located in COMMON 
between the 625 32-bit word PLAN loader 
area and the communication array. The 


format of the COMMON Switch Words is: 


1 The first word of the DYNAMIC file 
control block (ID(1)) of the file 
currently in use for statement sav- 
ing. The word may indicate either 
an open or a closed DYNAMIC file 
(see “Dynamic File Support", 
5.5.0). 


2 Contains the statement number of 
the saved statement that is to be 
executed next. If this parameter 
is zero, processing is in the norm- 
al manner (processing from PLAN 
input device). 


Statement number of 
the last saved statement to be 
executed. Note that if Switch Word 
2 contains a zero, Switch Word 3 
and Switch Word 1 may be used for 
any desired user system function. 


3 Contains the 


4-7 These switches are for the exclu- 
sive use of the application 
modules. Recommended usage of 
these switches as data pointers is 


outlined below. 


8 Contains the subscript of the first 
word of a block of the communica- 
tion array that may be treated as 
“erasable COMMON". The function of 
“erasable COMMON® is to provide an 
area of command and module 
independent memory that may be used 
by utility commands/routines and by 


user modules with the knowledge 
that they are not destroying system 
data required for continued 
execution. ; 


The length of “erasable COMMON" is 
assumed to be the number of words 
to the end of COMMON. Thus, no 
length specification is required. 


9 Contains the maximum size (in PLAN 
32-bit words) of COMMON for the 
phrase being processed. This 
allows the user to manage COMMON. 
It is the sum of the requirement 
for the loader, system switch area, 
managed array, and any additional 
nonmanaged COMMON. The minimum 
allowable value for this switch is 
640. 


10 Contains the number of PLAN words 
to be managed by the PLAN level 
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11-12 


management, as the managed communi- 
cation array. 


Setting this value to zero allows 
the use of the level error recovery 
facility of PLAN without initiating 
the disk access operations involved 
in the communication array data 
management. 


(Switch Words 11-12 may define one 
of two functions as defined below.) 


Contains the name of the user- 
written module that is to process 
error conditions, instead of the 
normal PLAN error processing proce- 
dures. User error modules may not 
call PLAN error subroutines (ERROR/ 
ERREX/ERRAT/ERRET, 5.11.6). PERRS 
will exit to the user error module 
via the checkpoint facility on each 
error on the 1130 version of PLAN. 
On S/360 PLAN, the named module is 
loaded as a LOCAL to process the 
error condition. 


An array in the following format is created 
in erasable COMMON. 


11 


12 





BYTE CONTENTS 
0-7 Program name causing diag- 
nostic call 
8-11 Error number (N1 from error 
subroutine call) 
12-15 Error code (N2. from error 
subroutine call) 
16-20 ID from cc. 76-80 


21 hexadecimal FF = system 


error, 0 = user error 
22 hexadecimal FF = abort, 0 = 
continue 
23. (Unused) 
24-27 Sequence 
28-31 Length of literal in 
characters 


32-107 Diagnostic literal 
108-111 Literal count of phrase 
112-561 Phrase text 


If Switch Word 11 is zero ora 
positive number, it indicates the 
count of the number of diagnostic 
messages that are to be written 
onto DYNAMIC file 255 of drive 0 
(error message queue file) before 
they are written on the device 
defined in Switch Word 12 or as a 
result of CALL ERLST. This option 
is not available if the diagnostics 
are processed by a _ user-written 
module. If this word is zero or 
one, diagnostics are written 
directly to the output device spec- 
ified in Switch Word 12. 


Contains the device code (see CALL 
tocs, 5.11.5) for the device on 
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which are to be 


written. 


diagnostics 


Contains switches governing the 
mode of error processing. The low- 
order four bits of the integer 
portion of this switch word govern 


PLAN error processing. 


BINARY 
BIT 
VALUE 
1 OFF Short form error 
messages 
ON Long form error 
messages 
2 OFF Stacked error 
processing 
ON Immediate error 
processing 
4 OFF Dynamic file error 
abort 
ON Dynamic file error 
continue 
8 OFF Permanent file error 
abort 
ON Permanent file error 
continue 
(See “PLAN System Diagnostic Proc- 


essing", 13.0.0) 


(Reserved) 
User Functions 


The switch words are initialized when PLAN 


processes any level 0 phrase. 


The settings 


assigned at that time are: 


SWITCH 


Ne 


INITIALIZATION VALUE 

0 (saved statement file) 

0 (saved statements not being 

executed) 

0 (last statement saved) 
0 (data list pointer one) 
0 (data list pointer two) 
0 
0 


(data list pointer three) 


{data list pointer four) 
490 (erasable COMMON) 
1150 (625+15+510) number of 


32-bit words in COMMON 
0 (managed array size) 
0 (error processing control) 
(standard PLAN output device) 
0 (error processing mode) 
0 (reserved) 
- (not initialized) 


The switch words should be set by the first 
command processed when PLAN is invoked to 
reflect the desired operating environment 


for this run. 
function is "PLAN JOB;" 
Commands", 


A suggested command for this 
(see "Standard PLAN 
4.5.0). 
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Note that any attempt to use the standard 
PLAN utility commands DUMP COMMON, DUMP 
SWITCHES, DUMP MANAGED, DUMP NONMANAGED, 
DUMP DYNAMIC, DUMP PERMANENT, DUMP PHRASES, 
and others will not be honored if Switch 
Word 8 is not set to a valid (positive) 


erasable COMMON pointer. 


The switch words are referenced in the same 
manner as the managed communication array, 
except that the subscript is negative in 
the range of -1 to -15. The following 
example illustrates the FORTRAN definition 
of a 350-word communication array, where M 
is the managed array and N is the non- 
managed array: 


COMMON L(625), LS(15), M(200), N(150) 


4.3.22 SWITCH WORDS 4-7 AS DATA POINTERS 


Serious consideration should be given to 
the use of the switch.words as data list 
pointers. Logic modules written to expect 
data strings in predefined positions of the 
communication array may be useless when an 
attempt is made to process another data set 
which for some reason requires a different 
starting CAP. 


The use of the switch word data list 
pointer concept allows processing of data 
no matter where it occurs. It also allows 
a user to shift his data bank location more 
freely without impact to application 
programming. 


The following example illustrates use of 
Switch Word 4 as a data list pointer: 


In the phrase definition “ADD PHRASE: 
NAME, I(-4)M, (M,200)A0...;" M is the 
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direct pointer to the first data item 
of the data list. Thus, CAP names of 
M, Mt1, Mt+2, etc., define successive 


values within the A data list. The 
user logic module need not concern 
itself with where the data array will 
actually be located because of this 
ability to reference the data symboli- 
cally. As a matter of fact, the pro- 
blem definer, at execution time, may 
change the location of the data list at 
will without requiring the programmer 
to change the logic module. Alli that 
is required of the problem definer is 
that he issue a command which gives a 
value to M. An example of such a 
command follows: 


NAME, M1; 


Switch Word 4, known as M, would receive 
the value 1. This value would be the 
Starting CAP for the 200-word array known 
as A. Since no override is specified for 
the default value zero, communication array 
locations 1, 2, 3, .«.., through 200, would 
be set to zero. 


Switch Words 4-7 are available to be used 
as data pointers allowing a maximum of four 
arrays to be directly referenced at any one 
time. However, it is possible to process 
more than four arrays at any one time. 
This can be done in an indirect manner. If 
one Or more of the Switch Words 4-7 point 
to CAPs which are not the start of the data 
arrays, but rather are the start of a list 
of CAPs which point to the data arrays, it 
is possible to define as many arrays as is 
required by the user (within the limits of 
core). This principle is illustrated in 
Figure 8. . 


- 
|CoNrenrs 25] Oo] O| Of [30]130|E T cl | <----- A ARRAY-—-->|<---B ARRAY--—>| ETC. | 

- - = = Hb I a a a I ei ee 
CAPS aa -5 -6 -7 25 26 27 28 29 30 130 

Figure 8. Schematic of the indirect data pointer 

Programs that allow for maximum interchan- Use of the data list pointer concept 
geability of data may be provided if a (Switch Words 4-7) is made easy by the two 


convention using Switch Word (3+N) for data 
list WN is adopted, where N is in the range 
of 1-4. If a value of N greater than 4 is 
required, the switch words should be used 
as indirect pointers as defined above. 


subroutines PARGO and PARGI. PARGO pro- 
vides for transfer of data lists froma 
user array to the communication array loca- 
tion pointed to by an indicated switch 
word. PARGI provides for transfer of data 
from the communication array to a user 
array. 
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The following example shows use of the 
PARGO routine in transferring array F, ina 
module, to communication array location 20. 
Example: 


COMMON L(625), LS(15), M(255) 
LS (4)=20 
CALL PARGO(4, F) 


In the above example, if F(1) contained a 
10, then communication array position 20 
would be set to 10 and F(2) through F(11) 
would be transferred to communication array 
positions 21 through 30. 


If the origin arrays are also in the 
communication array (COMMON), more effi- 
cient execution can be gained by coding the 
COMMON references with symbolic subscripts 
to avoid physical movement of data. For 
example, if the task of the module is to 
add up the data list, it can be coded: 


In the module creating the array: 
LS (4) =INDEX 


In the module summing the array: 
DIMENSION FILE(... 
COMMON L(625) ,LS(15),M(... 
EQUIVALENCE (FILE(1),M(1)) 
K=LS (4) 
LGTH=M (K) 
IJ=K+1 
I2=K+LGTH-1 
SUM=0. 
DO 2 I=IJ,12 
2 SUM=SUM + FILE(T) 
s 
oe 
6 


4.3.23 STATEMENT SAVE 

Any PLAN statement or group of PLAN state- 
ments, that define a procedure, can be 
saved in a PLAN DYNAMIC file for later 
execution. Identification of saved state- 
ments is by statement number and through 
use of the PLAN switch words. Statement 
numbers, in the range of 1 to 32,767, are 
prefixed to any PLAN statement that is to 
be saved. Thus, the PLAN statement takes 
on the general format shown in the follow- 
ing example: 


N COMMAND, DATA; N COMMAND, DATA;... 


In the example, N, when present, is the 
statement number. Note that it is a dis- 
tinct advantage functionally to keep N as 
small as possible. 


Statements are saved either implicitly or 
explicitly. The standard PLAN command SAVE 
starts the saving in the designated PLAN 
DYNAMIC file of the commands that follow. 
Saving operations are terminated when (1) a 
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new SAVE command, (2) a SEND (Save End) 
command, or (3) an unnumbered command is 
encountered. Statements saved explicitly 
are not executed during the saving opera- 
tion. Every statement to be saved must be 
numbered. The following example ililus- 
trates the use of the SAVE commanc for 
saving statements that describe a 
procedure. 


SAVE, FILE 45, DRIVE 1; 


5 COMMAND; 

6 COMMAND; 

7 COMMAND; 
SEND; 


The SEND command has no parameters. 


The SAVE 
parameters: 


command has the following 


FILE This data item defines the PLAN 
DYNAMIC file that is to be used 
for saving the commands. If the 
value is not provided, the cur- 
rent file number in Switch Word 1 
will be used. The file does not 
need to be open (see “DYNAMIC 
File Support", 5.5.0). 


DRIVE This data value defines the PLAN 
DYNAMIC Drive on which the state~ 
ment save file is located. If 
the value is not provided, the 
current value in Switch Word 3 
divided by 2048 will be used as 
the dynamic drive indicator. 


Numbered PLAN statements that are not 
explicitly saved are automatically saved 
(implicit) but are also executed. ADD 
PHRASE, ALTER PHRASE, and DELETE PHRASE 
commands may not be implicitly saved. 
Statements saved implicitly are stored in 
the file indicated by PLAN Switch Word i 
(see “Switch Words", 4.3.21). If a state- 
ment number is the same as ae statement 
already on that file, the new statement 
replaces the old _ statement. Any error 
found by PSCAN while scanning a statement 
to be saved implicitly will inhibit the 
saving of the statement. If no previous 
file has been designated, file 254 is used 
on drive 0. Note that the rules stated 


under "DYNAMIC File Support", 5.11.0, con- 
trol also the release of statement save 
files. Thus, a permanent statement save 


file may not be defined on DYNAMIC Drive 0. 
The failure of a check-entry with a "P" 
action code (*P‘*PHRASE‘S) prevents implicit 
saving of the PLAN statement. 


Saved PLAN statements may be executed at 
any time through entry of an EXECUTE com 
mand delineating the limits of the 
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statements to be executed. These limits 
are maintained in the PLAN switch words, 
and may be program-altered at any time. 
Execution always proceeds to the next- 
higher-numbered statement that is in the 
save file regardless of the order in which 
the statements were added to the save file. 
An example of the EXECUTE command is give 

below: ; 


EXECUTE, FROM 5 TO 10, FILE 45, DRIVE 


1; 
The EXECUTE command has’ the following 
parameters: 
FROM This data item defines the lowest- 


statement to be 

result of processing 
this command. If the number is not 
in the file, an error diagnostic 
(DFJ172) will be given. 


numbered saved 
executed aS a 


TO This data item defines the highest- 
saved statement that may be executed 
as a result of this EXECUTE command. 


FILE This data item defines the number of 
the DYNAMIC file that contains the 
saved statements to be executed. If 
this parameter is not specified, the 
current file number in Switch Word 1 


will be used. 


DRIVE This data defines the DYNAMIC drive 
number that contains the saved state- 
ment If the value is not provided, 
the current value in Switch Word 3 
divided by 2048 will be used as the 
DYNAMIC drive indicator. 


Execution of saved statements may also be 
controlled by any command or logic module. 
A saved statement is executed any time the 
PLAN loader is entered and (1) the pop-up 
list is found to be empty, and (2) system 
Switch Word 2 is not zero. 


Therefore, any logic module or any command 
that properly sets system Switch Words 1, 
2, and 3 may control (start, stop, or 
modify order) saved statement execution. 


The following commands illustrate the use 
of saved statements for looping within a 
command string. The first commands are the 
ADD PHRASE commands to define the control- 
ling statements. Note that statements 1-7 
adjust the sequence of execution. 
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ADD PHRASE: GO, I(-2)TO; 

ADD PHRASE: IF, I(1) TEST, 
TEST ?=TEST (2) ; 
ADD PHRASE: DO, 
SAVE; 

DO, “THIS‘...; 
DO, ‘THAT*'...; 
GO, TOT; 

DO, ‘SOMETHING" ,AO...3 


(-2): 


(5)LIT, I(3)A5, ...;3 


IF, :(A>4),4; 
EXECUTE, FROM 1 TO 7; 
NEXT PHRAS,...; 


SAM EWN 


The EXECUTE statement in the above example 


results in the following statement 
executions. 
STATEMENT 
NUMBER CAP DATA NAME SET TO 
1 3 A 5 
5 LIT 4, ‘THIS’ 
2 3 A 5 
5 LIT 4,*THAT® 
3 2 TO 7 
7 1 TEST + (TRUE) 
2 TEST(2) 4 
-2 TO 4 
4 3 A 5 
5 LIT 9,*SOME*,‘ THIN‘ ,G‘ 
<3 <A <0 
5 e e e 
6 e e e 
7 1 TEST ~ (FALSE) 


Execution continues with ‘NEXT PHRAS'‘'.. 


In the above example, execution of state- 
ment 3 causes control to pass to statement 
7 by setting the PLAN Switch Word 2 to the 
statement number of the next statement to 
be executed. Statement 7 tests the first 
position of the communication array for 
presence of a logical TRUE. If found to be 
TRUE, the contents of the second position 
of the communication array are moved to 
Switch Word 2 to indicate the next state- 
ment to be executed. Thus, a loop can be 
established and statements executed under 
program control. 


4.3.24 IMPLIED DATA ELEMENT DEFINITION 


Phrase data element definitions may be 
implicitly defined as successor elements to 
previously defined data elements. An 
implied data element definition may not 
follow a data element definition including 
a symbolic subscript. A data element 
definition is organized as follows: 


PFIS{ NIV 
eae GoM Seen Eom 
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(user-exit 
and scale 


F contains the format control, 
control, mode control, 
factor) 


S .contains the communication array sub- 
script (CAP) 


N contains the data name 


Vv contains the initialization values, 
check entries, and phrase-defined 
expressions 


The S and N sections may be implied as long 
as the sections to the left of the section 
to be implied are not included. A comma 
within the command indicates a new data 
element definition; therefore, any follow- 
ing data values are implicitly defined. 
The CAP of the implied data element defini- 
tion is one greater than the previous CAP. 


Implicit definition of S leads to a value 
of the next communication array position. 
Example: 


IP+2(10)A5, B7,... 


The above example would assign the standard 
value of 7, scaled by 100, in the integer 
mode, to the data name B at CAP 11. In the 
following example, B is assigned to CAP 13 
and is stored in floating-point mode. 
Example: 


(10)A‘LITERAL‘, B7,... 


In the previous examples the data name B 
was also optional. The location equivalent 
to B in the two examples could be 
referenced in an execution-time statement 
by A(2) and A(4), respectively. 


Additional implicit definitions are given 
in the examples below: 


(10)A5, ‘LITERAL’... 

(10)A, = A*100,... 

(10)A, :A[B... 

(10)A, *TA *POSITION 11 BAD"... 
(10,20)A, B32... 


If the implied value is the first item to 
be defined in the phrase, CAP 1 is assumed. 


Implicit definition also applies to the 
formula area. Execution of the following 


commands would yield a value of 1 in CAP 
10, 4 in 11, and a logical TRUE in i12. 
Example: 

ADD PHRASE: TEST, (10)A SO=At3, 

: (A=4) ?=+4; 

TEST,A1; 
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4.3.25 PSCAN EXECUTION SEQUENCE 


This section describes the sequence of 
operations during interpretation and proc~ 
essing of an execution-time statement. 


1. Phrase entry. The phrase definition is 
is retrieved from PFILE. The managed 
array is initialized, saved, and 
restored according to the rules defined 
by the level indicated for the phrase. 


2. VERB phrases. Program names are added 
to the pop-up list as the VERB phrases 
are encountered in a left-to-right 
manner. The lists processed at this 
time are those associated with the 
keyword VERB. 


3. Symbol table initialization. The sym- 
bol table is initialized according to 
the level of the phrase. Data names 
from this phrase are then added to the 
symbol table ina left-to-right order 
as defined in the ADD PHRASE (further 
information is described in the discus- 
Sion of Table 3 of the phrase entry 
table in Appendix E, 12.0.0). Data 
names from VERB phrases follow data 
names from the OBJECT phrase with the 
data names from the leftmost VERB 
phrase entered last. Symbol table con- 
struction is illustrated in Figure 9. 


The symbol table construction effect is 
illustrated in the following example: 


ADD PHRASE: ONE, LEVEL 1, (2)A, (1)A, 
(3)B1,0; 

ADD PHRASE: THR, (2)B, (4)C; 

ADD PHRASE: TWO, C, VERB, (3)C; 


ONE; 
TWO THR, C1, B2, A3; 


The communication array will contain 
the following data after the above 
execution. Underlined letters repre- 
sent the final symbol table entries. 


CAP CONTENTS SYMBOL TABLE ENTRIES 


1 3 A Cc 
2 2 A B 
3 1 B ¢c 
4 0 Cc 
ae a cw can a ca en eee ED a ee na a ——> 
TIME 
Note that the final 


symbol table definition of each data 
name is underlined. Entries not under- 
lined are subsequently overridden. 


The first command 
issued is “ONE;"*. Therefore, PSCAN 
first analyzes that PFILE phrase entry. 
Since ONE is a level 1 command, a new 
symbol table is started. The first 
data item encountered as PSCAN scans 
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the phrase entry from left to right is 
A. A is entered into the symbol table 
as the data name for CAP 2. The next 
data item encountered is also named A. 
The CAP specified for A this time is 1. 
The previous reference of A is eli- 
minated from the symbol table, and the 
new reference for A is recorded in the 
symbol table. The data name A now 
refers to CAP 1. The next data item 
encountered is named B. B's definition 


causes an entry to be made in the 


symbol table that specifies that CAP 3 
is to have an associated default value 
of 1. The last data item encountered 
in this phrase is the value 0. Since 
no CAP is explicitly defined for this 
value, PSCAN assigns this value to the 
next available CAP. Therefore, CAP 4 
is assigned the value 0. 


The following diagram 
represents the results of the steps 
described above. 


CAP CONTENTS SYMBOL TABLE ENTRIES 
A 
A 
1 B 


0 


FWN Ee 


If the reader uses the method of analy- 
sis outlined above in accordance with 
the rules for symbol table initializa- 
tion, the diagram that shows the final 
symbol table entries should become 
apparent. Hint: Analyze the OBJECT 
phrase "THR" before the VERB phrase 
"TWO". 


Data initialization. Default values 
defined in the ADD PHRASE are stored in 
the communication array. Default 
values from VERB phrases (right-to- 
left) are processed following proc- 
essing of default values from the 
OBJECT phrase. 


Input analysis. Execution-time data is 
converted and moved to the communica- 
tion array. This phase includes all 
data defined in the input stream as 
analyzed in the left-to-right order. 


Phrase-defined expressions. All 
expressions defined in the ADD PHRASE 
including the formula area, are eval- 
uated. The formula area for each 
phrase is evaluated following data item 
expressions. 


Program list. Program lists are added 
to the pop-up list. 


Check entries. All check entry tests 
are performed in a left-to-right order 
and the appropriate specified action is 
executed. If there are VERB phrases 
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(see “Verb Designation and Program 
List", 4.3.5), steps 6 through 8 are 
repeated in a right-to-left manner. 


The following example illustrates the 
contents of the communication array 


following expression execution of 
phrase-defined and execution-defined 
expressions: An execution-defined 


expression is defined as any expression 
contained in the execution-time input 
stream. 


ADD PHRASE: ONE, LEVEL 1, A, BO, =0, 
=6, $0 B(3)=9; 
ONE, $1A5: (B=1)?$9, A4&, B=1, 5, 7,:$1; 


CONTENTS ACCORDING 
CAP NAME TO PSCAN SEQUENCE 
A 5 4 5 
B 0 1 

5 0 
7 6 9 


FWNHE 


PSCAN execution for the above example 
occurs in the sequence listed below: 


1. Default values defined in the ADD 
PHRASE are stored in the communica- 
tion array. This causes B, which is 
assigned CAP 2, to be set with a 
default value of zero. 


2. Execution-time data as defined in 
the command “*ONE" is converted and 
moved to the communication array. 
The first data name encountered, 
scanning left to right, is A. 


A has been given the data value 5. 
Hence, CAP 1 (from previous A 
definition) will be given the value 
5. Next, PSCAN encounters the log- 
ical expression ": (B=1)?$9". Since 
B at this point in time contains a 
zero, the branch to formula number 9 
is not taken. PSCAN, next, sets 
A(CAP 1) to 4, B(CAP 2) to 1, and 
CAP 3 and CAP 4 to:5 and 7, respec- 
tively. The next data item encoun- 
tered, %:$1", causes an uncondition- 
al branch back to formula number 14. 
Once again A(CAP 1) is set to 5. 
The logical expression ": (B=1) ?$9" 
this time, however, is TRUE (since 
the arithmetic expression B=1 was 
executed above), and ao branch is 
taken to formula number 9. But, 
since formula number 9 has not been 
defined in this command, a branch is 
taken to the semicolon (see “Formula 
Area", 4.3.20), and PSCAN execution 
continues as described in 3. 


3. Expressions defined in the ADD 
PHRASE, including those in the for- 
mula area, are evaluated. The eval- 
uation of the expressions in the 
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formula area follows the evaluation 
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Finally, the formula ‘%$§0B(3)=9" is 


of the data element expressions. evaluated. Evaluation causes a 9 to 
Since CAP 2(B) was just tested, the be placed in B(3). Since B(i) is 
PSCAN CAP pointer now moves over to CAP 2 and B(2) is CAP 3, then B(3) 
CAP 3 and the value zero is’ stored. is CAP 4&4. Hence, a 9 is stored in 
PSCAN then sets CAP 4 to 6. CAP 4. 
WHAT 
IS LEVEL 
OF THIS 
PHRASE? 
| 
| 
| 
EXECUTE | 
PHRASE | pa 1 
| | START NEW | 
A SYMBOL TABLE | LEVEL 1 |SYMBOL = { 
| SAVE AREAS }----—--------+-------------- | TABLE b---4 
| | L—————————— 4 
| I l 
| [ | 
{ | | 
p-7—t--- (crc 1 | LEVEL 2 fotos 4 { 
[ {LEVEL 1 | on eae rama ae SSeS l | 
| |OR BLANK----— | #1 | | OR BLANK | | | 
| {AFTER 1 1 | | | AFTER LEVEL 1 _ | | | 
[ I | {hess =e S5 1 { | l | 
|WRITE {LEVEL 2 cael | | LEVEL 3 | | | 
|SYMBOL |OR BLANK—-——— ++» -}----4----- - - - -- - - - | | 
| TABLE {AFTER 2 {i #2 | | OR BLANK | | 
{TO DISK | | | | AFTER LEVEL 2 |READ IN | | 
| SAVE LSS 4 { | SYMBOL { | 
JAREA(S) |LEVEL 3 | p>] | | LEVEL 4 | TABLE | | 
JAS SHOWN|OR BLANK b+p }----4+--------------------------- -~|AS SHOWN | | 
| {AFTER 3 -——-7++py] #3 | | OR BLANK | | 
| | itt | AFTER LEVEL 3 | | | 
| | [}} t-—-------—--4 | | | | 
| | [| tt | | | t | 
| LEVEL 4 =| L-py pram tan nnn nnn >| | | 
| {OR BLANK | ped #4 | BLANK | | | 
| [AFTER 4 ~——~-p| | AFTER LEVEL 4 | | | 
ey eal eae a ee 4 L--__,—---~ J | 
. ----------- | | 
| | ADD SYMBOLS] | { 
t_-__—.._-_____-__- +--+ --------- 4 FROM THIS /-——--—--------~~~-----~~~~ J { 
| PHRASE | | 
| [Kh nnn ne 4 
[aa eee er J 
Figure 9. Symbol tables save and restore logic 
4.3.26 MULTIPLE DATA ELEMENT DEFINITIONS multiple definitions is shown in the fol- 


Multiple data elements may be defined and 
referenced to the same communication array 
definition. This is possible because the 
PSCAN CAP pointer does not normally incre- 
ment to the next CAP until the comma that 
signals the end of a data element's defini- 
tion is encountered. The general format of 
a command with the additional organization 
requirements that must be followed in using 
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IFITSTN{I CIT LIE! XI 
ba le ks 


F contains any format indicators (user- 
exit control, mode control, and scale 
factor) 
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S is the communication array subscript 
(CAP) 


N contains the data name 


Cc contains the default numeric or logical 
data values. It is this section only 
of the data element definition that may 
be propagated through an array by a CAP 
defined as an Implied Do. 

the 


L contains default literal data 


values 
E contains the check entry information 
x contains the phrase-defined expressions 


The following example illustrates a sample 
entry defined to set an array containing 
100 values to FALSE, to set ae standard 
literal to the first five array positions, 
and to test for the proper use of the data 
name and corresponding literal. In other 
words, the following example has been 
created to ensure that if the data name 
ARRAY is specified in a command, its asso- 
ciated expected literal is also present. 
If the associated literal is omitted, error 


messages are issued. Example: 

ADD PHRASE: SAMPLE, (25,124) ARRAY- 
"STANDARD DATA *A‘NO DATA‘ *RA‘NAME 
ONLY',... 

In the above example, the following 

sequence of events takes place within 

PSCAN: 

1. A logical FALSE (7FFFFFFF) is set to 
communication array positions 25 to 
124. Note that ARRAY is entered into 
the symbol table equivalent to CAP 25 


and that the PSCAN CAP pointer rests at 
CAP 25. 


20 "STANDARD DATA" is 
through ARRAY (5). 
set to ARRAY(1). 


set into ARRAY(2) 
The literal count is 
Since the PSCAN CAP 
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pointer rests at CAP 25 and since a 
Single quote literal definition 
requires a character count to be 
stored, the count is stored in CAP 25 
(ARRAY(1)). The literal itself is 
stored in CAPs 26-29 (ARRAY(2) through 
ARRAY(5)) as STAN,DARD,bDAT and Abbb, 
respectively. The literal character 
count is 13, which does not include the 
padded blanks in CAP 29 but does 
include all other blanks (CAP 28) which 
May be part of the literal itself. 
Note: The PSCAN CAP pointer still sits 
at CAP 25 since the data item terminat- 
ing comma has not been encountered. 


A check entry is made on CAP 25 for not 
FALSE. If the value is found to be 
FALSE, the diagnostic "NO DATA" is 
generated and execution of this phrase 
is terminated. The location could be 
FALSE only if entered as a data value, 
for example, ARRAY-, since initializa- 


tion places a standard literal in the 
location. 

A second check entry is made on 
ARRAY(1) for real. Since FALSE has 
previously been checked, this is 
essentially e test for TRUE, although 


FALSE would also cause failure of this 
check. If found to be TRUE (or FALSE), 
the diagnostic "NAME ONLY" is generated 
and execution of this phrase is 


terminated. A TRUE value can result 
from a user entering the following 
command: 

SAMPLE, ARRAY,...; 


If a data name is defined and no 
associated value is specified, a logi- 
cal TRUE is’ placed in the CAP repre- 
sented by the data name. Since the 
sample ADD PHRASE contains check 
entries which test for this type of 
error, no harm is done. The phrase is 
terminated with a message and the user 
reenters the corrected command. 
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41.4.0 REVIEW OF LANGUAGE DEFINITION 


This section is a self-teaching introduc- 
tion to language definition under PLAN. It 
does not cover every possible option. 
Reference will be required to other parts 
of the manual for in-depth explanation and 
understanding of the questions asked. 


The material is presented as a series of 
numbered questions. Following the question 
is either a "yes"(Y) or a "no"(N) = entry 
indicating an action to be taken according 
to the answer selected. If only one answer 
follows the question and it is not the 
selected answer, this indicates that the 
next question is to be processed. Material 
in the answer section that is underlined 
indicates entries to be made in generating 
the ADD PHRASE. Transfers to other num- 
bered questions are preceded with the numb- 
er sign (#). A G instead of, or following, 
a Y or WN entry indicates a transfer to the 
indicated question number. The following 
example illustrates the organization of 
this section. The first step is initiated 
with the question "Is today Tuesday?". If 
the answer is "yes", the “Y" option is 
executed. This tells the user to enter 
“TUESDAY" into the command. If the answer 
is “no*", the "N" option is executed and the 
user enters the day of the week into the 
command in literal form. Processing con- 
tinues at step Al. The G ("GO TO") could 
have been eliminated since execution of the 
next entry is always implicit. Example: 


#27. Is today Tuesday? 

Y. *TUESDAY' G. #A1 
N. ‘LITERAL"' (Enter day of week for 

literal) G. #A1 


#A1. Is there a new phrase to be added to 
the system? 

Y. ADD PHRASE: NAME, (NAME is one to 
five words. Only the first three 
characters of each word are consid- 
ered significant.) 

N. G. #21 


Are there programs to be executed 
each time this phrase is executed? 
Y. PROGRAM‘ NAME1L 


N. G. #A4 
#A3. Are there additional program names to 
be added? 
Y. zNAMEn G. #A3 
Ne Oy 
#A4. Is this phrase one of a series of 
dependent phrases? 
Y. LEVEL 
N. G. #A6 
#A5. Is this the independent phrase of the 


dependency group? 
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Y. 
N. 
#A6. 


Y. 
N. 


#A7. 
Y. 
N. 

#A8 e 


Y. 
N. 


#A9. 


#B1. 


Y. 
N. 


#B2. 


Y. 
#B3. 
Y. 
#B4. 
Y. 
N. 
#B5. 
N. 
#B6. 


Y. 
N. 


#B7. 
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1, 
n, (n=2,3,4 indicating 
levels of dependency) 


increasing 





Is this phrase to be used as a 
modifier to another phrase? 

VERB 

G. #A9 


Are there programs to be executed 
after the programs associated with 
the object (nonverb) phrase? 

* PROGA 

G. #A9 


Are there additional programs for the 
verb list? 
zPROGN G.#A8. 


e 
—L 


Are there to be data items that 
require special user-written programs 
to convert the data? 

EXIT 

G. #B1 





Is the program to be executed with 
user exit 1 named EXIT1, user exit 2 
named EXIT2, and user exit 3 named 
EXIT3? 


*PROG1, PROG2, PROG3*, (*PROGI,2,3° are 
the names of the programs to be 
associated with the respective user 
exit.) 

Are there data items to be defined 
for this phrase? 

G. #B2 

G. #c1 


Is the data for this data item to be 
converted using one of the three 
user-exit programs associated with 
this phrase? 

Un (n=1,2 or 3) 


Is the data item to be stored in the 
integer mode? 


L 

Is the data item to be scaled before 
it is stored (multiplied by some 
power of 10)? 

Pp 

G. #B6 


Is the power of 10 greater than zero? 
+n (n ranges from 1-7) 
-n (n ranges from 1-7) 


Is the data item to be stored in the 
system switch words? 

(-n) (n ranges from 1 to 15) 

G. #B36 


Does the data item require identifi- 
cation so that it may be identified 
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#B11. 
Y. 
N. 
#B1i2. 
Y. 
N. 
#B13. 
N. 
Y. 


#B1i4. 


at execution time? 

NAME (NAME is any combination of 1-3 
alphabetic characters. If more than 
three characters are provided, they 
are ignored.) 


Is there to be a standard (default) 
value provided for the data item? 

G. #B13 
Is the standard data value to be 
logical? 

#B11 


Is the standard data value to be 
literal? 

G. #B12 

mnn (nnn is a numeric field contain- 
ing an optional sign, decimal point 
and exponential modifier.) G.#B13. 


Is the logical value to be FALSE? 
- G. #813 
+ G. #B13 


Is the count of the number of literal 
characters to be stored along with 
the literal text? 

*LITERAL TEXT‘ 

"LITERAL TEXT" 


Is the data item to be checked for 
status (TRUE, FALSE, REAL, NOT 
FALSE) ? 

G. #B27 

bal 

Must the location. be REAL for the 


test to pass? 
R G. #B18 


the condition be TRUE for the 
to pass? 
#B18 


Must 
test 
T G. 


the condition be FALSE for the 
to pass? 
#B18 


Must 
test 
F G. 


Must the condition be TRUE or REAL 
for the test to pass? 

G. #B18 

Proceed and define a new data item 
that is set by evaluation of a logi- 
cal expression defining the condi- 
tions to be set. Then define a check 
on the new data item. G. #B27. 


Is PLAN to give a standard PLAN 
system literal if the test fails? 
G. #B26 


Is the program list to be modified if 
the test fails? 
G. #B25 


If the test fails, is a user-supplied 
diagnostic to be written followed by 


#B24,. 


Y. 


#B25. 


Y. 
N. 


#B26. 


Y. 


#B27. 


#B29. 
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continuation of processing? 
C G. #B24 


Is a user-supplied diagnostic to be 
written if the test fails followed by 
initiation of the PLAN error recovery 
scheme? 

A G. #B24 


Is a new phrase to be invoked if the 
test fails? 

P 

Please tell PLAN development what you 
would like to do if the test fails. 


Is the text of the new phrase to be 
given in the phrase; not provided as 
text in the communication array? 
“PHRASE TEXT ‘* (terminal blank in 
text required) 

(CAP) (CAP is the location within the 
communication array that contains the 
PLAN literal of the phase to be 
invoked. A space is provided at the 
end for insertion of the 
semicolon.) G. #B26 


Is the diagnostic text to be given in 
the phrase; not provided in the com- 
munication array? 

*DIAGNOSTIC TEXT* 

(CAP) (CAP is the communication array 
location that contains the character 
count for the PLAN literal that is 
the diagnostic text.) G. #B26 


Is the program list to be given 
within the phrase; not provided in 
the communication array? 

* PROGA, PROGB,..." . 

(CAP) (CAP is the communication array 
position that contains the character 
count of the literal text for the 
list of programs to be added to the 
pop-up list if the test fails.) 


Is there an additional test to be 
made against this data item (communi- 
cation array) location? 

the 


Is this data item to be set as 


result of evaluation of an equation? 
G. #C1 

Is the equation arithmetic; not 
logical? 

=EXPRESSION (Expression may contain 
matched parentheses to indicate the 
order of evaluation; the arithmetic 
operators +, <-, *, /; arithmetic 


constants; symbolic operands that are 
symbols in the symbol table fdr this 
phrase.) G. #B35 


Is this operand in the expression a 
relational expression (contains =, >, 
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#B30. 


Y. 
N. 


#B31. 
#B32. 


Y. 
N. 


#B33. 


#B34. 


#B35. 


Y. 
N. 


#B36. 


Y. 
N. 


#B39. 


Y. 
N. 


#C1. 


#C2 es 


Y. 
N. 


#D1. 


* or <)? 

a 

OPERAND G. 
any name in 
table.) 


#B34 (The operand may he 
the current system symbol 


Is the left side of the relational an 
expression? 

EXPRESSION 

SYMBOL or CONSTANT 


RELATIONAL OPERATOR (>, -, =) 


Is the right side of the relational 
an expression? 

EXPRESSION 

SYMBOL or CONSTANT 


d 


Is there to be another operand in the 
expression? 


logical operator G. #B29 


Is there to be another expression 
defined for this data item? 

G. #B28 

2 G. #C1 

Is the data item to be assigned to a 
specific communication array 
location? 

(n) (n ranges from 1 to the limit of 
the communication array.) G. #B7 


( 


Is this operand of the symbolic 
storage assignment a constant? 
constant G. #B39 


Is the symbolic operand to represent 


the location of the symbol; not the 
contents of the symbol? 

S*symbol 

symbol 

Is there another operand in the’ syn- 
bolic designation? 

arithmetic operator G. #B37 

) G. #B7 

Are there more data items to be 
defined? 

G. #D1 


Is the new data item to be assigned 
to the next-higher communication 
array location, and is the format 
(mode, user-exit control, and scale 
factor) identical to the data item 
just defined? 

G. #B27 

G. #B2 


Are there additional tests to be made 
or values to be set by expression 
evaluation that require looping or 
branching within the expressions? 
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N. 
#D4. 
Y. 
N. 
#D5. 


N. 
Y. 


#D5.1 


Y. 
#D6. 
Y. 
#D7. 


Y. 


#D11. 


Y. 
N. 


#D12. 
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G. #E1 

$0 

Will this formula require transfer 
to/from elsewhere in the formula 
area? 


$n (n is in the range of 1 to 1,024.) 


Is this element used to assign a data 
value to a data item or to execute a 
conditional branch? 


NAME (any valid name within the cur- 
rent symbol table) 

G. #D21 

Is the data item to be set asa 
result of a logical formula, not an 


arithmetic formula? 


=NAME G. #D20 


Is this operand to be a relational 
expression? 

NAME G. #D1i0 

( 


Is the relational expression a test 


for logical TRUE? 
NAME=+) G. #D10 

Is the relational expression a test 
for logical FALSE? 

NAME=-) G. #D10 


Is the relational expression a test 


against an EBCDIC character mask? 


NAME = “MASK") (MASK contains only 
the characters to be tested.) G. 
#D10 

Is the left side of the relational an 
expression; not a simple name? 
ARITHMETIC EXPRESSION 

NAME 

Is the relational operator =, >, or 
<? 

relational operator) 

What else is desired? 

Is there to be another operand in 


this expression? 


logical operator 
#D5 


(not, and, or) G. 


Is the data item to be set as a 
condition of the result of the logi- 
cal expression? 

2 

a G. #D1 5 

If the logical expression is TRUE, is 
the data item to be set equal to the 
result of a logical expression? 


slogical expression G. #D1i5 
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#D13. 


#D15. 


Y. 
N. 


#D16. 


#D17. 


Y. 


If the logical expression is TRUE, is 
the data item to be set equal to the 
result of an arithmetic expression? 


= arithmetic expression G. #D15 


If the logical expression is TRUE, is 
processing to continue at a different 
formula number? 

$n (n is any other formula number 
defined in this phrase formula area.) 


Is processing to continue at the next 
formula without change to the value 
of the data item if the result of the 
logical expression is FALSE? 


G. #D19 
' 


If the result of the logical expres- 
sion is FALSE, is the data item to be 
set equal to the result of a logical 
expression? 


slogical expression G. 


If the logical expression is 


#D19 


FALSE, 


is the data item to be set equal to 
the result of an arithmetic 
expression? 

=arithmetic expression G. #)D19 


#D18. 


#D19. 
Y. 
N. 


#D20. 


Y. 
N. 


#D21. 
Y 6 
N. 


#E1 e 
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If the result of the logical expres- 
sion is FALSE, is processing to con- 
tinue at other than the next formula? 
$n (n is any valid formula number) 


Are there more formulas required? 
2 Ge #D1 


G.#E1 


Is the evaluation to be as a result 
of an arithmetic expression (are more 
operands required) ? 


Operator operand G. #D21 


G. #D19 


Is the element to be a branching type 
element ? 

3$n G. #D19 (n is the number of the 
next formula to execute.) 


G. #D1 

i G. #A1 

Now, go back to the sections on 
“Language Definition", 4.3.0 and 


"Language Use", 4.2.0. 
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4.5.0 STANDARD PLAN COMMANDS 


This section discusses the statements dis- 
tributed as a standard part of the PLAN 
system. The only command that is a pro- 
grammed portion of PLAN is ADD PHRASE. All 
other commands must be added to the system 
through use of ADD PHRASE. This section 
provides a discussion of the facility pro- 
vided by a_ set of these phrases that are 
entered into the language definition dic- 
tionary (PFILE or DFJPFIL) as a part of the 
PLAN system generation. On System/360 DOS 
and OS PLAN, program names are prefixed 
with the characters "DFJ". The standard 
phrases shown represent standards for 1130 
PLAN. On System/360 there may be minor 
variations. These variations may be noted 
in the phrase listings in the appropriate 
Operations Manual. Spacing within literals 
in the phrase definitions may not accurate- 
ly represent that of the distribution 
commands. 


4.5.1 ADD PHRASE 


This command is added to the language 


definition dictionary when it is 
initialized. 
ADD PHRASE: ADD PHRAS, (1)0, LEVELO, I(- 


13)1, PROGRAM 'PHRAS, PHUDT'‘; 

ADD PHRASE may be altered to list all added 
phrases by adding PIDMP to the program 
list. 

4.5.2 ALTER PHRASE 


ALTER PHRASE provides the ability to delete 
an existing version of a phrase and replace 
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it with a new copy. (For use, see "PLAN 
Language Definition", 4.3.0) 


ADD PHRASE: ALTER PHRASE, I(1)-1,LEVELO, 
I(-13)1,PROGRAM *PHRAS, PHUDT, PHUDT’; 


ALTER PHRASE may be altered to list all 
altered commands by adding PIDMP to the 
program list. 


4.5.3 DELETE PHRASE 


DELETE PHRASE provides the ability to 
remove commands from the language defini- 
tion dictionary. (For use, see “PLAN Lan- 
guage Definition", 4.3.0.) 


ALTER PHRASE: 
LEVELO, 


DELETE PHRASE, (1)-1, 
I(-13)1, PROGRAM‘ PHRAS, PHUDT' ; 


DELETE PHRASE may be altered to list all 
deleted commands by adding PIDMP to_ the 
program list. 


4.5.4 PLAN JOB 


ALTER PHRASE: PLAN JOB, LEVEL 0, I(-1) 
FILE, SAVED, TO, LISTS, LB, LC, LD, ERASE, 
COMMON, MANAGED, NERM, DEVICE, I(1)SHORT-, 
LONG-, STACK-, IMMEDIATE-, DRIVEO, DFI-~, 
PFI-, (-11)UMOD, I(-13)FORMO, $0 FORM: (LONG) 
=FORM+1, FORM: (IMM) ?=FORM+2, FORM: (DFI) ?= 
FORM+ 4, FORM: (PFI) ?2=FORM+8, TO=TO+DRIVE 
*2048; 
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fo. eee 5 aE aie ceo 5 ar raccnaa 5 RRA AT A 4 Ben eedaniaurocaes Lo ee eee ‘. 
{| PLAN JOB | | | | DEFAULT| CHECKING | 
| FUNCTION | NAME | CAP | MODE |VALUES | RULES | EXPRESSIONS | 
-------------—---—------- 4-—-------4-------}------}-------} ---------4-----------------+4 
{| SAVED STATEMENT FILE | FILE | (-1) | I |**NOTE | | { 
------~-------——---------- 4--------- 4------- t------ t------- $--------- $--~-------------- 1 
| INITIAL SAVED STATEMENT | SAVED | (-2) | I | | | | 
~-------~---------------- tenn nnn af 
| END SAVED STATEMENT | TO | (-3) | Ir | \ | =TO+DRI*2048 | 
—-------------——-------- +--------- 4---~--- +------ +-------}--------- +--—-------------- : 
| DATA LIST A POINTER | LIStTs {| (-4) | I | | | | 
---------------—-------- 4$--~---~--}-------}------}--—----} ---------} -----------------f 
| DATA LIST B POINTER | LB | (-5) | I | | { | 
<< ---=--- hanna nnn fn nn nn nn 
| DATA LIST C POINTER } Lc } (-6) | TI | | | | 
<a +—————-—- f-- ao +-————- 4--——~-- $———-----— {------------—---- { 
| DATA LIST D POINTER { LD | (-7) | I i | | | 
——---------— —-——--—- fanaa ff ff 
| ERASABLE COMMON POINTER | ERASE | (-8) | I ! | { | 
—-~----------——-------- 4-—--—----}-------}------4-------}--------- 4 -----------------f 
| SIZE OF COMMON | COMMON | (-9) | I | | | | 
|--------------—----------- 4-—--~---- +------- +------ 4------- $~-------- 4----------------- 1 
| SIZE OF MANAGED ARRAY | MANAGED | (-10) | I | { | | 
+ ——------ 4--------- 4------- $------}------- $--------- $------~-----=---- : 
| ERROR FILE QUEUE COUNT | NERM | (-11) | I | | | | 
-------------—-—-------- +-~---——--- 4------- +------ +------- $--------- 4----------------- : 
| DIAGNOSTIC MODULE(*NOTE) | UMOD | (-11) | LIT {| | | | 
---------------—-------- $f anf ff ff 
| DIAGNOSTIC DEVICE | DEVICE | (-12) | I | | | | 
~~ === == +-—-----—- +------- +------ +——---—~ $-------—~ fran { 
| DIAGNOSTIC FORMAT | FORM {| (-13) | I Ke | | : (LON) 2=FORM+t1 = | 
| I | | | | | : (IMM) ?=FORM+2 = | 
| | | | | | | s(DFI)?=FORMt+4 = | 
| | | | | { | : (PFI) ?=FORM+8 | 
~-~-~----------—-------- 4---------}-------}------4-------}---------}-----------------4 
| SHORT FORM INDICATOR |] SHORT | (1) | LOG |FALSE | j { 
-------------——-------- 4---------}-------4------}-------}---------4 ----------------- 
{| LONG FORM INDICATOR | LONG { (2) | LOG |FALSE | | | 
nnn ana nn nnn tnt nn nnn 
| STACKED ERROR INDICATOR | STACK } (3) | LOG {FALSE | | | 
}-------------------------- 4--------- $------- +------ +-—---— }--------- $----------------- : 
| IMMEDIATE ERROR IND. | IMM } (4) | LOG |FALSE | | | 
----—---------—----------- {--------- 4------- +------ +------- }--------- +----------------- { 
| SAVED STATEMENT DRIVE | DRIVE } «5) | I {0 { | j 
~-~------------—-------- hanna nn nnn 
| DYNAMIC FILE ERROR IND. | DFI | (6) | LOG |FALSE | | { 
---+---------------------- 4+--------- $------- +------ +------- +--------- $---~---~~-------- { 
| PERMANENT FILE | | | li: | | | 
{| ERROR INDICATOR | PFI { (7) . | LOG |FALSE | | | 
t_—___-_----~----__---------- ee 2 eee eens Mc cs cas pinnae i Sr a J 
*NOTE: “UMOD" and “NERM" are mutually exclusive and may not be used together. 


**#NOTE: 


Default values are not provided because the 15 PLAN switch words are automatical- 


ly reset as a result of the execution of any level 0 command. 


PLAN JOB provides initialization functions 
for any PLAN run. This command, or one 
that provides the functions of this com- 
mand, should be the first command processed 
when PLAN is invoked. The command meets 
the requirement that a level O phrase be 
the first phrase processed and sets’ the 
parameters controlled by the system switch 
words. System accounting functions may be 
conveniently facilitated by adding the name 
of an accounting module as a program list 
to this command. A sample of the command 
at execution time is: 


PLAN JOB, MANAGED 200, ERASABLE 240, 
COMMON 900, LISTS 30,50,200,209, SAVED 20 
TO 30 FILE 3, DRIVE 2 SHORT, STACKED, 
DEVICE 102; 


The above example illustrates: 


1. The setting of the managed array to a 
size of 200 PLAN words. 
2. The establishing of the beginning of 
erasable COMMON at CAP 240. 
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The following parameter discussions 
table above) 


The defining of the total size of 
COMMON to 900 32-bit words. 
The defining of four CAP indices (30, 


60, 200, 209) used in referencing a 
maximum of four data lists. 

The designating of the short form of 
diagnostic. 


The specification of the indicator to 
cause error stacking (STACKED). 


The designation of the device upon 
which error messages are to be printed 
(DEVICE 102). 


(see 
give a breakdown of the PLAN 


JOB options: 


Ls 
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SAVED STATEMENT FILE. This parameter 
defines the DYNAMIC file number (1-255) 
from which the next PLAN statement (a 
Saved statement) is to be executed. 
The parameter will not be used if the 
next PLAN command is not a saved 
statement. 


INITIAL SAVED STATEMENT. If the next 
PLAN statement is to come froma saved 
statement file, this parameter defines 
the number of the first statement that 
will be executed. If this parameter is 
specified, the FILE, DRIVE, and TO 


‘parameters should also be specified. 


END SAVED STATEMENT. 
statements are to be executed next, 
this parameter defines the highest- 
numbered saved statement that will be 
executed. 


If saved PLAN 


DATA LIST POINTER. This 
used to define the CAP 
to the maximum of four 
lists. These data 
referenced by PSCAN for storing data, 
by PARGO and PARGI for transmitting 
data, and by user program modules. 


parameter is 
indices for up 
possible data 
lists may be 


LB. This parameter provides a direct 
pointer to the second of the data lists 
defined above. 


Lc. This parameter provides a direct 
pointer to the third of the data lists 
defined above. 


LD. This parameter provides a direct 
pointer to the fourth of the data lists 
defined above. 


ERASABLE COMMON. This parameter 
defines the communication array posi- 
tion (CAP) that is to be treated as the 
beginning of erasable COMMON. Erasable 
COMMON extends from the CAP position 
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11. 


12. 


13. 


14. 


LS. 


16. 
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identified to the end of the communica- 
tion array. This parameter must be set 
to some positive value within the range 
of the communication array in order for 
many of the standard PLAN commands to 
execute. The switch word is reset to 
490 each time a level 0 command is 
encountered. 


SIZE OF COMMON. This parameter defines 
the total size of COMMON (including 
communication array, Switch words, and 
resident loader). 


SIZE OF MANAGED ARRAY. This parameter 
defines the number of PLAN words that 
are to be managed according to the 


level structure of the commands to be 
processed. If this value is set to a 
positive integer and statements have a 
level assignment, the managed array 


save file must be present for the 


saving of data. 


ERROR FILE QUEUE COUNT. If error ciag- 
nostics are to be written onto logical 
file 255 of logical drive 0 instead of 
directly to an output device, then this 
parameter will specify the Inaxximum 
number of messages that are to be 
allowed on the file before the messages 
are to be written to the diagnostic 
device. 


DIAGNOSTIC MODULE. This parameter is 
used to specify the name of aie user- 
written module that is to process error 
conditions rather than using the normal 
system processing. Note that this 
option precludes the error queue option 
and is in lieu of writing the diagnos- 
tics onto the diagnostic device. 


DIAGNOSTIC DEVICE. If a diagnostic 
module is not specified, this parameter 
specifies the sequential file device 
code (see "CALL I0CS", 5.11.5) upon 
which the diagnostics. are to be 
printed. This switch word is reset to 
100 each time a Level 0 command is 
encountered. 


DIAGNOSTIC FORMAT. This parameter 
should not be referenced by a user. It 
is set as a result of use of items 15, 
16, 17, 18, 20, and 21 (see "PLAN 
System Diagnostic Processing", 13.3.0). 


SHORT. The word “SHORT" is’ specified 
if the short-form option is desired. 
Short-form diagnostics mean that the 
phrase being processed when the error 
is detected is not listed with the 
error. (See "PLAN System Diagnostic 
Processing", 13.0.0.) 


LONG. 
the 


This parameter is used to set 
long-form diagnostic indicator. 


15 
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Long-form diagnostics include the 
EBCDIC image of the phrase which caused 
the error, along with the diagnostic 
message (see "PLAN System Diagnostic 
Processing", 13.0.0). 


STACK. This parameter sets the indica- 
tor to cause error stacking. In this 
mode of processing, errors are written 
to the output device only when the 
error module is scheduled by the PLAN 
loader or when the stack overflows. If 
the stack overflows, the checkpoint 
facility must be used to allow sched- 
uling of the error module. (See "PLAN 
System Diagnostic Processing", 13.0.0.) 


IMMEDIATE. This parameter sets the 
indicator to cause diagnostics to be 
written to the output device one-by-one 
as they are encountered. The check- 
point file and checkpoint programming 
must be available to function in the 
IMMEDIATE mode. (See “PLAN System 
Diagnostic Processing", 13.0.0.) 
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error procedures when an error is 

detected by the DYNAMIC FILE support 

subroutines. 
21. PERMANENT FILE ERROR INDICATOR. This 
parameter determines the PLAN system 
error procedures when an error is 
detected by the PERMANENT FILE support 
subroutines (see “PLAN System Diag- 
nostic Processing", 13.0.0). 


4.5.5 SET LITERAL 


SET LITERAL is the command used to define 
standard literals or tables for storage 
into a GDATA type file. The literals are 
Maintained in a manner that makes’ them 
accessible to the subroutine PHIN. 


SET LIT, NAME‘*PLITF", NUMBERn, 
FILE}, DRIVEm; 


"LITERAL', 


ADD PHRASE: SET LITERAL, PROGRAM‘ PDIAG‘, 


19. SAVED STATEMENT DRIVE. This parameter I(-8)M, I(M)FILE254, I(M+1) NAMEO, I(M+4) 
specifies the PLAN DYNAMIC drive number DRIVEO, I(M+5)NUMBER-*RA* UNDEFINED LITERAL 
that will be used when the SAVE state- NUMBER‘ , I(M+6)LITERALO, (M+1) TEST-* 
ments are processed. TA‘ UNDEFINED FILE NAME": 

(NAME>0) & (NAME<9) ; 

20. DYNAMIC FILE ERROR INDICATOR. This 
parameter determines the PLAN system 

ea ee re 2 a aaa Sanaa oe Soe 2 aN Sarna oa EAE oon ee 1 

| SET LITERAL | | | | DEFAULT| CHECKING | | 

| FUNCTION | NAME | CAP | MODE |VALUES | RULES | EXPRESSIONS | 
~------------------------- f--------- 4 -- == ff ff 
| ERASABLE COMMON | | | | | | | 
| POINTER | M | -8 | | | | | 
~------------------------- $--------- +------- $------ t------- $--------- {----------------- { 
| LITERAL FILE NUMBE | FILE | M i = j254 | | | 

--~----------—---------- 4--------- 4 -=----- ff ff 
| LITERAL FILE NAME | NAME | Mtl {| I {| oO | | | 
|--------------------------- $--------- 4------- +------ +------- {--------- {----------------- : 
| LITERAL FILE | | | | | | | 
| DRIVE | DRIVE | M+t4 |} I } oO | |. | 
|--------------—----------- $--------- 4------- $------ ------- +------—-- {--—-------------- : 
| LITERAL NUMBER | NUMBER | Mt5 {| |FALSE | *RA | | 
-~---------------—--------- 4---------4------- 4 ------}-------f---------f----------- 4 

{ LITERAL TEXT OR TABLE | LITERAL | M+6 | I | 0 | | | 

[--------------—-—--------- 4----—---- 4------- $--~--- $--~=--— $---—---— fo--------=--—---- : 

| TEST FILE NAME | TEST { Mtl. | {FALSE | *TA | : (NAME>0) 6& | 

| | | | | | (NAME<9) | 

Gest ie eS Se ee | Sena nea Me Ss et b vene eer Hs rn eae eee es Sane asta ee ee ae ee 4 

1. ERASABLE COMMON POINTER. This param- parameter should be defined only in 


eter points to the position within the 
communication array defined as erasable 


COMMON. This parameter (Switch Word 8) 
is normally set with the PLAN JOB 
command. 


LITERAL FILE NUMBER. This parameter 
defines a number to be used to process 
the GDATA type literal file. The 


Situations where 254 would cause con- 
flict with other processing on 1130 
PLAN. 
3. LITERAL FILE NAME. This parameter 
defines the name of the GDATA file in 
which literal processing occurs. Note 


that this parameter must be given. 
Otherwise, the check entry defined 
STD. COMMANDS (4.5.0) 67 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


ase i a ama ca aad : | ao 

| LIST LITERAL | | 

| FUNCTION | NAME | CAP 
Bo ee a aS 4 4———..-——. 

| LITERAL FILE NUMBER | FILE } 1 
cata Sa ne a a A 4——--—-—--} 

| LITERAL FILE NAME | NAME [32 
cesta Soe eeeee 4. |... 

| LITERAL FILE { | 

| DRIVE | DRIVE | 5 

|--------------—-—--------- $-~------- $------- 

| LITERAL OUTPUT DEVICE | NOD | 6 

Cpe eae oe aoe ee eae ie ae e Renner 

1. LITERAL FILE NUMBER. This parameter 
defines a number to be used to process 
the GDATA type literal file. The 
parameter should be defined only in 
situations where 254 would cause con- 
flict with other processing on 1130 
PLAN. 

2. LITERAL FILE NAME. This parameter 
defines the name of the GDATA file in 
which literal processing occurs. Note 
that this parameter must be given. 
Otherwise, the check entry defined 
under “test file name" will fail and 
the phrase will not be executed. 

3. LITERAL FILE DRIVE. This parameter 
defines the PERMANENT drive on which 
literal file is located. Failure to 
provide this parameter results in the 
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under “test file name" will fail and 
the phrase will not be executed. 


LITERAL FILE DRIVE. This parameter 
defines the PERMANENT drive on which 
literal file is located. Failure to 
provide this parameter results in the 
assumption that the file is on PER- 
MANENT drive zero. 


LITERAL NUMBER. This parameter defines 
the identification number for the lit- 
eral to be processed. Note that fail- 
ure to supply a literal number will 
result ina phrase abort error diag- 
nostic. If the number is the same as 
an existing literal, the existing lit- 
eral is removed from the file prior to 
adding the new literal. 


LITERAL TEXT. This parameter provides 
the literal text for the literal to be 
added to the file. If this parameter 
is not provided (literal length zero) 
the existing literal of the same number 
is removed from the file. Note that 
tables can be maintained by this com 
mand and by the PHIN/PHOUT subroutines 
if the following convention is followed 
in setting up the data: 


Hi 
| MODE {VALUES | 
+ 
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Oa end 
iN {KK {Ws | Wot ete ie Wn il 
oe a aac 

where: 

N Table or literal number 

K Count of bytes in table or liter- 

al character count 
Wa First 32-bit word in table or 


first four literal characters 
Wn Last 32-bit word in table 


7. TEST FILE NAME. (See “Literal File 


Name“ above). 


4.5.6 LIST LITERAL 


LIST LITERALS is a command that produces a 


listing of all literals maintained in a 
specified literal file. 
ADD PHRASE: LIST LITERALS, LEVEL 1, PRO- 


GRAM‘ PLITL', 1I(1)FILE254, NAME-*A‘LITERAL 
FILE NAME NOT DEFINED’, I(5)DRIVEO, NCD100, 
(35) "NUMBER LENGTH TEXT OF PLAN LITERAL"; 


|DEFAULT| CHECKING 


—4 
1 
1 
! 
| 
| 
| 
1 
| 
| 
| 
| 
| 
t 
| 
| 
1 
I 

ai 


RULES | EXPRESSIONS | 
~-----}------- $---------}-----------------] 
I ,254 | | | 
~-----}------- }---------4-----------------4 
I [FALSE | *A | | 
------ $-------+---------}-----------------| 
l | | | 
I 10 | | | 
---—-- 4-------4---------}--------—--------4 
I {100 | | | 
Sees PSs ee ee a ed 
assumption that the file is on PER- 
MANENT drive zero. 
4, LITERAL OUTPUT DEVICE. This parameter 


defines the output device that is to be 
used to list the literals. The stand- 
ard parameter results in the use of the 
current PLAN output device. 


4.5.7 COMMUNICATION ARRAY DUMPS 


DUMP COMMON is a command that produces a 
hexadecimal printout of the commuriication 
array. Identical print lines are 
suppressed. 


DUMP MANAGED is a command that produces a 
hexadecimal printout of the managed portion 
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of the communication array. Identical 


‘print lines are suppressed. 


DUMP NONMANAGED is a command that produces 
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I (M) 
I(M+15) 


ALTER PHRASE: DUMP SWITCHES, I(-8)M, 
NNN-2, (M+11)A"SWITCHES", “LENGTH", 
NOD100, PROGRAM* PCDMP*; 

ALTER PHRASE: 


DUMP COMMON, I(-8)M, I(M) 


a hexadecimal printout of the nonmanaged NNNO, ‘MANAGED ARRAY*,  ‘NONMANAGED ARRAY‘, 
portion of the communication array. "SWITCHES", "LENGTH", 
Identical print lines are suppressed. I(M+15)NOD100, PROGRAM*PCDMP*; 
DUMP SWITCHES is a command that produces a ALTER PHRASE: DUMP MANAGED, I(-8)M, I(M) 
hexadecimal printout of the PLAN switch NNN1, * MANAGED ARRAY‘, "SWITCHES", 
words. "LENGTH", I(M+15)NOD100, PROGRAM *PCDMP'; 
Note carefully that these are blank-level ALTER PHRASE: DUMP NONMANAGED, I(-8)M, 
phrases. Any attempt to use them following I(M)NNN-1, (M+6) B* NONMANAGED ARRAY', 
a PLAN phrase abort error will result in "SWITCHES", "LENGTH", I(M+14)NOD100, PRO- 
the phrase being skipped. GRAM *PCDMP‘; 
aaa a aa pa acca aaa aaa cara [ooo oo (amare Toons oe eee 1 
DUMP | | | |DEFAULT| CHECKING | 
| FUNCTION | NAME | CAP | MODE |VALUES | RULES | EXPRESSIONS | 
|--------------—----------- +----—--- 4------- +------ +------- $--------- $----------------- : 
| ERASABLE COMMON | { | | | | | 
| DEFINITION | M {| -8 oe | | | | 
}--------------—-—--------- $-------—- 4------- +------ $------- +--------- $----------------- : 
| FUNCTION SWITCH | NNN | M 2 | | | | 
{| | DUMP COMMON | | | j 0 | | { 
{| DUMP SWITCHES { | | {-2 | { { 
| | DUMP MANAGED | | | j-1 | [ | 
| | DUMP NONMANAGED | | | j+1 | | | 
|--------------—-—--------- 4—------- 4------ +------ +------- +--------- 4----------------- { 
| OUTPUT DEVICE | NOD { Mt15 | I }100 | | | 
Wake ee ee ees We ee Se ee ect ree cree eae ee aR J 
1. ERASABLE COMMON DEFINITION. This AALTER PHRASE: DUMP PERMANENT, I(-8)M, I(M) 
parameter, a pointer to that portion of FILE 255, I(M+t2)STARTO, I(M+3) ENDO, I(M+t4) 
the communication array to be used as DRIVEO, (M+t5)A"DRIVE FILE LENGTH", (M+t12) 
erasable COMMON, is normally set by the NAME* as I (M+15) NOD1L00, 0, 
PLAN JOB command. PROGRAM* PFDMP * ; 


2. FUNCTION SWITCH. The appropriate value 
within the word (0, -2, 1, -1) distin- 
guishes between DUMP, DUMP SWITCHES, 
DUMP MANAGED, and DUMP NONMANAGED func~- 
tions, respectively. 


3. OUTPUT DEVICE. This parameter defines 


the sequential device code to be used 
for output. 
4.5.8 FILE DUMPS 
ALTER PHRASE: DUMP DYNAMIC, I(-8)M, I(M) 
FILE255, I(M+2)STARTO, I(M+t3)ENDO, I(M+4) 
DRIVEO, (M+t5S)A*DRIVE FILE LENGTH", (M+12) 
NAME" *I (M415) NOD100, 1, PROGRAM 
*PFDMP* ; 


DUMP DYNAMIC is a command that produces a 
hexadecimal printout of the PLAN DYNAMIC 
file. Identical print lines are 
suppressed. 


DUMP PERMANENT is a command that produces a 
hexadecimal printout of a PLAN PERMANENT 


file. Identical print lines are 
suppressed. 
The limits of the dump are defined by the 


START and END operands. If these are 
omitted, the entire file is dumped. 


Note carefully that these phrases are blank 
level, and will therefore be skipped if 
PLAN level recovery is invoked as the 
result of an error in a nonblank-level 
phrase. 
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Bae a ee eae oe eae eer Sabie 
{ DUMP PERMANENT | | 
| FUNCTION | NAME | CAP 
}--------------—---------- $----—----}$------ 
| ERASABLE COMMON | | 
| INDEX | ™M | -8 
}----------------—--------- f----—--—- }------ 
| FILE NUMBER | FILE | M 
cco smn sos sis sss rm ki i se esti Sm 4---~-----4------ 
| START OF DUMP | START | Mt2 
= 4+——----——--} 
{ END OF DUMP | END | M+3 
a en DS GE be ees On mn NED 4----—--—---4------ 
| DRIVE | DRIVE | Mt4 
sn! mn sn a gm sc gus sd 4---------+------ 
| FILE NAME | NAME | M+12 
ae ee re ee cnr cE SD ts SNE aD a en ee em 4—---------4--- 
| OUTPUT DEVICE | NoD | M+15 
yee SE SO SN YS 4+-------—-—--——+ en 
| DUMP TYPE SWITCH | | M+16 
Be se se we cl Sy cin NT sts ED Dae em tS nn ee a en 
1. ERASABLE COMMON INDEX. This index 


defines the location within the com- 
munication array known as ERASABLE COM- 
MON. The index is normally set by the 
PLAN JOB command. 


FILE NUMBER. This parameter defines 
the file number of the file that is to 
be dumped. 


START OF DUMP. This parameter defines 
the number of the PLAN word within the 
file at which the file dump is to 
start. 


END OF DUMP. This parameter defines 
the number of the last PLAN word within 


the file that is to be dumped. If the 
parameter is not given (parameter is 
set to zero), the full length of the 


file will be dumped. 


DRIVE. This parameter defines the PLAN 
DYNAMIC or PERMANENT drive number on 
which the file to be dumped is located. 


pe Eat Bea Sa ete ee at ete ees 
| SAVE | { 
| FUNCTION | NAME | CAP 
}-----~- Hanne a +—_------- +------ 
| | sw | -1 
a aro a , eer ee 4------ 
{ I | -2 
[ 4--------- 4------ 
| ERASABLE COMMON POINTER | M | -8 

ee a ew SD OND SPADE et ch ND st ce 4+----—-----+4------- 
| DYNAMIC FILE | FILE | ™M 
es es eS eh A Dc ED OD +--------~-+4------ 
| DYNAMIC DRIVE | DRIVE | M#1 
Gn i ces a a ec a ae ee ee ee A tao Sen 
+NOTE: 
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Qo et re ee ee oo ee 1 
| |DEFAULT] CHECKING | | 
| MODE |VALUES | RULES | EXPRESSIONS | 
+------ +------- $--------- fonn nnn nnn nnn { 
I | i | | 
| <r | | | I 
$---——- t-----—- foaa—-— = {-------------+--- { 
} I 4255 [ | | 
4-----~ +-—------ +--------- $--—-----~-------— { 
i <r |o | [ | 
+ +------- $--------- $----------------- { 
i; <r [0 l | | 
+------ 4------- {--------- {--—--—-----—--- ~-{ 
} <r [0 | | | 
t----—- $~------ $--------- {----~------------ i 
{ LIT |BLANK | | | 
+------ +------- $--------- $-~--------------- { 
} I {100 | { | 
t---—-— --—-— }—-—-———— | La { 
i I [0,1 | | l 
Epes Soe ere epee ean Dh eis ee a J 

6. FILE NAME. This parameter defines the 
name of the file to be dumped. 

7. OUTPUT DEVICE. This parameter defines 
the sequential device code that will be 
used for output. 

8. DUMP TYPE SWITCH. This parameter 


pe HH 


— 


determines whether a DYNAMIC or a 
MANENT file is to be dumped. 


PER- 


4.5.9 STATEMENT SAVE COMMANDS 


ALTER PHRASE: SAVE,, I (-1) SW, -1, I (-8) M, I (M) 
FILEO, I(M+1)DRI-1, $0 SW: (FIL>0) ?=FIL, 
SW (3) : (DRI>-1) & (DRI<5) ?=DRI*2048; 


SAVE is a command to allow saving of the 
PLAN statements that follow the SAVE com- 
mand on a PLAN logical file. Each state- 


ment to be saved must be prefixed with a 
statement number. Saving of statements is 
terminated by (1) a SEND command, (2) any 
command that does not have a statement 
number, or (3) another SAVE command. 


doit ee ae et eee eS ite Ie ct 
|DEFAULT| CHECKING | 

MODE |VALUES | RULES | EXPRESSIONS | 
SS oo a ae a 
I [ | | | 
Sse BSR acetate ana | 
I {-1 | ] | 
-—---— Toes [ae ee 
I i | | { 
== Se et 
I | 0 | | | 
aoc 1 ee eee 
I {-1 { | *NOTE | 
as a 2 a [ee ne | 


$0SW: (FIL>0) ?=FIL, SW(3) : (DRI>-1) & (DRI<5) ?=DRI*2048 
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1. DYNAMIC FILE. 
the number of the PLAN DYNAMIC file on 
which the following statements are to 
be saved. If this parameter is 
omitted, the current file number in 
Switch Word 1 will be used. 


2. DYNAMIC DRIVE. This parameter defines 
the number of the DYNAMIC drive on 
which the following PLAN statements are 


This parameter defines 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


SEND is a command used to terminate the 
saving of a series of PLAN statements. 


ALTER PHRASE: EXECUTE, I(-1)SW,0, I(-8)M, 
I(M) FROM 0, I(M+1)TO 0, I(M+2) FILE 0, I(M+ 
3) DRIVE -1,(M)F*TA*INVALID STATEMENT NUMBER 
OR DRIVE‘, $0 SW: (FIL>0) ?=FIL, DRI: (DRI<0) 
2?=SW(3)/2048-.5 !:$55, DRI: (DRI<0O)?=0, $5 
FRO:4 ((DRI>-1) &(DRI<5)) ?=+, SW(3):(TO>0) 
?=DRI*20484+TO !=DRI*2048, SW(2): (FRO>0) ?= 


to be saved. If this parameter is FRO, FRO: (SW(2)>0); 
omitted, the current file number in 
Switch Word 3 divided by 2048 will be 
used as the DYNAMIC drive indicator. EXECUTE is a command to initiate execution 
of commands saved in the specified state- 
ALTER PHRASE: SEND; ment save file. 
Ce ee = {Sst 7 SSS 5 a ae: | SaRRURRiee nae A ee oe 1 
| EXECUTE | | | {DEFAULT| CHECKING| { 
| FUNCTION | NAME | CAP | MODE [VALUES | RULES | EXPRESSIONS { 
|~---------------—--------- 4--------- 4------- +------ $-——---- }------—-- $----------------- : 
| | sw [-2 | r | | 
|-----~-----------—--------- {--------- t------- t-~----}-----— {--------- +--—-------------- { 
| | 1-8 | © | ] | | 
|-—-------------—_---------- 4----—--- 4-------+------ 4------- $--------- {------------—---- { 
| FIRST COMMAND TO EXECUTE | FROM | M {} I { 0 | *NOTE1 | | 
---------------—--------- $---------}-----—-} ------4------- 4 ---------}------------—--- 
| LAST COMMAND EXECUTED | TO | Mtl |} I | 0 | { | 
-------------------------- 4--------- 4------- +------ {------- +--------- $----------------- : 
| STATEMENT FILE NUMBER | FILE 1 M+t2 {| I |O0 | | | 
-------------—-—--------}-------~- +-----— +------ 4------- $--------- 4----------------- { 
| STATEMENT DRIVE NUMBER | DRIVE | Mt3 | I f-1 | | | 
|---—---------------------- 4--------- 4------- $------}------- $------——- }----------------- { 
| PARAMETER CALCULATION | | | | | | *NOTE2 | 
Ue E iene eae eae i aero cae Ware eee i ier ae One eee peepee eeeres Hane hese epee Sa ee a Jj 
*NOTE1 *TA‘INVALID STATEMENT NUMBER OF DRIVE‘ 
*NOTE2 SOSW: (FIL>0) ?=FIL, 
DRI: (DRI<0) ?=SW(3)/2048-.5!:$5, 
DRI: (DRI<0) ?=0, 
$5FRO: 4 ( (DRI>-1) & (DRI<5) ) ?=+, 
SW(3) : (TO>0) 27=DRI*20484TO!=DRI*2048, 
SW(2) : (FRO>0) ?=FRO, 
FRO: (SW(2) >0) 
1. ERASABLE COMMON POINTER. This param- 4. FIRST SAVED. This parameter defines 


eter defines the location within the 
communication array of ERASABLE COMMON. 
The pointer is normally set by the PLAN 
JOB command. 


2. DYNAMIC DRIVE. This parameter defines 
the PLAN DYNAMIC drive number that is 
to be used to process SAVED statements. 
If this parameter is omitted, the cur- 
rent drive specified by Switch Word 3 
divided by 2048 will be used. 


3. DYNAMIC FILE. This parameter defines 
the PLAN DYNAMIC file number that is to 
be used to process SAVED statements. 
If this parameter is omitted, the cur- 
rent save file specified by Switch Word 
1 will be used. / 


the number of the lowest-numbered SAVED 
statement to be executed. If this 
statement cannot be located, a PLAN 
diagnostic (DFJ172) will be produced. 


5. LAST SAVED. This parameter defines the 
highest-numbered SAVED statement to be 
executed. Execution continues from the 
first SAVED statement identified 
through continually higher-numbered 
statements to the statement identified 
with this parameter. If this parameter 
is omitted, only the statemens. indi- 
cated by Switch Word 2 will be 
executed. 
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Goi. Choa ee eg ee, a | 
JSAVE, FILE 2, DRIVE 3; 


| 
16 A; | 
{9 B; | 
{18 C; 


In the above example, when the SAVE command 
is encountered, all the numbered statements 
that follow (6, 9, 18) will be stored in 
the PLAN DYNAMIC file 2 on drive 3. This 
is known as explicit saving because the 
statements are stored for execution at a 
later time, and not’ executed now. see 
"EXECUTE" command, discussed above.) 
Implicit saving, is utilized where state- 
ment storage and execution are accomplished 
as the statements are read. 


It is important to note that execution of 
the SAVED statements will occur by state- 
ment numeric sequence, not by position 
within the input SAVE stream. For example, 
if a statement number 15 was placed after 
statement 18 in the stream, it would still 
be executed ahead of 18 if at a later time 
an EXECUTE command was encountered utiliz- 
ing the parameters FROM 9 and TO 18. 


4.5.10 PHRASE TABLE DUMP 
T(500) 


ALTER PHRASE: DUMP PHRASES, SYS- 


TEM1130, I(501)NOD100, I (503) LEVEL1, 
LEVEL1, (200) "CHECKSUM", "PHRASE NAME", 
(Sr ee es 5 Pacem nba ania 
| DUMP PHRASES { | 
| FUNCTION | NAME | CAP 
caine aera saan 
| SYSTEM DESIGNATION | SYSTEM [| 500 
ae ae ata aa ne oe Bae eae 4——-. 
| OUTPUT DEVICE {| DEVICE | 501 
Ss OE ea cae A rE oe Ae ee eee nde a ee SR GE —--—~----+--- a ae oe: 
{| PRINTOUT LEVEL | LEVEL { 503 
a a ee oe Se ace I ae a i ces lt a 
1. SYSTEM DESIGNATION. This parameter 
defines the system for which the PFILE 
(PLAN language dictionary) is being 


dumped. The phrase for the appropriate 
system contains the necessary standard 
value so that the user should never be 
required to specify this parameter. 


2. OUTPUT DEVICE. This parameter defines 
the sequential device code to be used 
for output. 


3. PRINTOUT LEVEL. This parameter defines 
the complexity of the phrase listing to 
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"LEVEL TYPE-OBJECT", “ENTRY SIZE", 
"VERB", “SUBSCRIPT NAME VALUE RANGE INDEX", 
"EXIT PROGRAM LIST", “SYMBOL EXIT FORMAT 
SCALE SUBSCRIPT | EXPRESSION", "PROGRAM 
LIST", “TEST LOCATION ACTION", “LITERAL , 
LIST",SUBSCRIPT, “LOCATION MODE FACTOR 
EXPRESSION", (510)-*TP‘CON DUM PHR 
I(504)DRIO'; 

(1130 STANDARD PHRASE) 

ALTER PHRASE: CON DUMP PHRASES, 
(281) "INTERPRETIVE EXPRESSIONS", "VERB 
PROGRAMS", END OF PHRASE TABLE DUMP", 
PROGRAM* PTDMP*, (505) "PFILE"; 


DUMP. PHRASES is a command that produces a 
tabulation of the phrases that exist within 
PFILE. 


CONTINUE DUMP PHRASES is the continuation 
of the DUMP PHRASES command and should not 
be invoked by itself. 


The module PTDMP produces the phrase dump. 
It requires XACES, XTRAC, XPRNT, and XBIT, 


which are called as subroutines. PTDP1, 
PTDP2, PTDP3, PTDP5, and PTDP6 are also 
required. They are called as monitor 


locals on 1130 PLAN and are loaded as PLAN 
system local modules on OS and DOS PLAN. 
These modules are special purpose programs 
that have no use in any other environment. 


pee Rr ha er ey 
|DEFAULT| CHECKING | 

MODE |VALUES {| RULES | EXPRESSIONS | 
SEEN Ppa | a VR 
{ j1130, | | I 
{ <r [360 I { | 
+------ ~—~--—}--------- $--—-------------- : 
| I {100 { | | 
+-—---+------- $--——--——~ fea nnn { 
f <r 2 | | | 
oS eee Selene seen hls ati lanl ances J 
be produced. Each higher level incor- 


porates all items of the lower levels. 


The items listed below represent informa- 
tion that is produced at the various print- 
out levels. Figure 10 shows sample lines 
from the dump. Enclosed items are explana- 
tory notes about the sample output lines. 
It is strongly recommended that the reader 
make a diligent attempt to correlate the 
phrases as defined in this section with the 
listing produced with the DUMP PHR, LEVEL 
6; command through use of Figure 10. 


LDP FPRVDAEE] LAW OVEAGL FMLA EaEN NR Bsa 
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CHECKSUM 1 


(see Appendix E, PFPWVTAB Phrase Verb Validity Table) 


PHRASE NAME LIST LIT LEVEL 1 TYPE-OBJECT ENTRY SIZE 16 1023 0 0 













ADDRESS OF PHRASE ENTR 
IN DUMP PRODUCED BY 
DUMP PERMANENT 


RECORD/6 








IF THESE INDICATORS 
ARE NONZERO THEY 

GIVE THE RECORD AND 
DISPLACEMENT OF THE 






SUBSCRIPT NAME VALUE RANGE INDEX 
=i 00000000 36 


32-BIT VALUES FROM 
VALUE IMPLIED DO 





SUBSCRIPT NAME VALUE RANGE INDEX 
1 A 00018000 
1 B 00100000 
A(1), B(1) SYMBOLIC 32-BIT 
etc. SUBSCRIPT VALUE 
SYMBOL EXIT FORMAT SCALE SUBSCRIPT EXPRESSION 
M I -8 


A 
B 


M 
M+7 


I 
R 
NOD Mt15 
USER 
DATA EXIT SCALE CAP SYMBOLIC 
NAME NO. FACTOR CAP 


PROGRAM LIST 


PHRAS 
PHUDT 
PHUDT 
TEST LOCATION ACTION LITERAL, LIST, OR SUBSCRIPT 
*R ; UNDEFINED LITERAL NUMBER 





Figure 10. Phrase table dump explanation 
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LEVEL ITEM LISTED 
0,1 Phrase name 
Phrase level 
Type (object or verb) 
Number of internal records (80- 
bit on 1130, 64-bit on System/ 
360) required for phrase 
PFILE ADDRESS of phrase entry 
Chained phrase indicator (0 0 
means no chained phrase) 
Checksum of phrase 
2 Initialization (Default values) 
Subscript 
Name 
Value 
Range 
Index 
3 Symbol Table 
Symbol 
User-exit number 
Format 
Scale factor 
Subscript 
Subscript expression 
4 Program lists 
5 Check entries 
Test 
Location 
Action 
Literal, list, or subscript 
6 Expressions 
Data area 
Formula area 


fe helt tier er hE anaes a 
{ Iocs | I 

| FUNCTION | NAME | CAP 
en a ny i ce cr tc 4—--~-—------4+ a ae ae oe oe ane 
| ERASABLE COMMON POINTER | | -8 

a a i i i in St i Sich ni Cems min a an ss mae ee ce ces ee 
| PLAN INPUT DEVICE | INPUT | 1 
sc a es sc ces a eps Ge eas ns wn msc +-——- ins casts er + a cs a 
| PLAN OUTPUT DEVICE | List {| 2 
Leta i aires at a eee a cares ca ci ee ss i ed lee cs ce acini 


rIocs is a level O command on 1130 PLAN that 
allows the PLAN input and output devices to 
be altered. 


1. INPUT. This parameter must specify the 
input unit that is to be used for input 
of the following PLAN commands. Valid 
arguments are 2501, 1442, and 1131. 


2. LIST. 
output unit that is 


This parameter must specify the 
to be used for 
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4.5.11 ERROR LISTING 


ALTER PHRASE: DUMP ERRORS, PRO‘ PEDMP*‘; 


DUMP ERRORS is a command that causes all] 
diagnostics in the error queue file to be 
listed on the PLAN diagnostic device. 


4.5.12 IOCS CONTROL ON 1130 


ALTER PHRASE: IOCS, LEVELO, PRO‘ PIOCS", 
[(1) INPUT1131, LIST1131, I(-8)1, S$OINPUT: ( 
INPUT=1131) ?=3, INPUT: (INPUT=2501) ?=2, 
INPUT: (INPUT=1442) ?2=1, LIST: (LIST=1131) ?= 
103, LIST: (LIST=1403) ?=102, LIST: (LIST= 
1132) ?=101, INPUT: (INPUT=1) | (INPUT=2) = | 
(INPUT=3) 2=INPUT!=0, LIST: (LIST=101) | 
(LIST=102) | (LIST=103) ?=LIST!=100; 


Nooo es a Rane eS iW te ep eee Mewes Se ee pe w | 
| |DEFAULT| CHECKING| 

| MODE [VALUES | RULES | EXPRESSIONS 1 
+------ +------- {===--=-—— = 1 
i ret 1 | | [ 
fe aaa acaconar fe | 
} =I 41132 | { r 
f------ ------- $--------- ----------------- { 
| xr $4131 | i r 
he an nee en eee 5 a se i a A a cc en ses sccm i mca tr sa ei i em ins eo a | 


output of following PLAN diagnostics. 


Valid arguments are 1132, 1403, or 
1131. 
ALTER PHRASE: CARD, I(-8)M, I(M)INPUTO, 


I(M+1)LIST100, PROGRAM‘PIOCS*, S$OINP: (INP= 
2501) 2=2, INP: CINP=1442) ?=1, LIS: (LIS=1403) 
?=102,LIS: (LIS=1132) ?=101, INP: (INP=1) | 
CINP=2) 2INP!=0, LIS: (LIS=101) | 
(LIS=102) ?=LIS!=100; 
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a AC a SE ARS ES SE OD FE CE RO RL NS OE EY OE ORT URES OU RY Ca Se See = 
CARD | | 
| FUNCTION | NAME | CAP 
cco cee i pn oat mos an cus tna os emit ms Sa a ai Se Sl 4---—-----—-4----~-- 
| ERASABLE COMMON POINTER | M {; -8 
Fe sss a a a Gs es nt ss os es is emo acme mi is oka aos us ak +------~---4--~---- 
| PLAN INPUT DEVICE | INPUT | M 
cn seta as es es as eee es Cee nin wd ete a 4-----—---—-4------ 
| PLAN OUTPUT DEVICE | LIst | M+1 
ma ta a as a ac cea ls wae races Ga ass es as ln ts De eis ae eens ee ae ee oa 


CARD is a blank-level command on 1130 PLAN 
that allows changing input to either card 


reader and/or out put to either line 
printer. 
1. INPUT. This parameter must specify the 


the next PLAN 
Valid arguments 


card reader from which 
input is to be read. 
are 2501 or 1442, 


Feit a ate ee Seta qoceeeiseis pes 
| TYPE { | 
| FUNCTION | NAME | CAP 
ee ee ew wae a mS rs Sen en iran teen eS Se Sane eee em nn nan 4-----—----4------ 
| ERASABLE COMMON POINTER | M | -8 

a Se ae ee ea eee 
| PLAN INPUT DEVICE | N | ™M 
—--—-—---—-- —-—-- - —- ——- ——-- -—- + a as a a can le + es 
| PLAN OUTPUT DEVICE | | M+1 
a ie a a em ee Sec cp in ss aa Ss es 4 — ———— 


TYPE is a blank-level command on 1130 PLAN 
that sets the console typewriter/printer as 


the input/output device from/to which the 
next PLAN input/output is to be 
read/written. 


ALTER PHRASE: LON, LEVEL 1; 

LON is a level 1 command that has no 
function other than to fulfill the require- 
ment that a level 1 command be processed. 


(a Se ee {SS 2 eames 
| SET PAGE LENGTH | | 
| FUNCTION { NAME | CAP 
Rae es ce es +-------——- ———--~—---—-— } --- ---- --}--- += 
| ERASABLE COMMON POINTER | M | -8 
eae teeters waa} J 
| PAGE LENGTH | PGL | M 
at Sea a a 
| OUTPUT DEVICE {| NOD | Mt 
Nite eee i BERRA SS fone cea aes Sa 
1. PAGE LENGTH. This parameter defines 
the number of lines to be printed on a 
page before a logical EOF is generated 
and an automatic eject (skip to 1) is 
effected. 


2. OUTPUT DEVICE. This parameter defines 
the sequential device code with which 
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5 teas oS a hepa iaten ueah eg a Saray a ers 1 
| | DEFAULT | CHECKING | | 
| MODE {VALUES | RULES | EXPRESSIONS | 
+------ +------- {--------- {----------------- 4 
{ <r | | | | 
+--———- 4------- +——----—— }--—-—--------——- : 
| © ef 90 | [ | 

-}------ {------- $--------- }----------------- 4 
| I 100 | | | 
eee : eee Bat ee a ca ds a J 

2. LIST. This parameter must specify the 


pointer on which the next PLAN diag- 
nostic is to be printed. Valid argu- 
ments are 1403 or 1132. 


ALTER PHRASE: 
PROGRAM* PIOCS® ; 


TYPE, I(-8)M, I(M)N3, 103, 


To a ee Mo ae Mise te eae cee ene ES eo gy 1 
| |DEFAULT| CHECKING | | 
| MODE [VALUES | RULES | EXPRESSIONS | 
| eee Gm t==2-5-=—= : ga aaa mae era { 
{| Ir | | | | 
{= {-=--=-= {2=-=-2=—= sae ater acre a { 
| I {| 3 { i | 
= $---==— 1S ae aaa 4 
{ I 4103 { | | 
. a hh ins, eo Se a J 


4.5.13 PAGE LENGTH DEFINITION (OS/DOS ONLY) 


ALTER PHRASE: 
I (M) PGL60, 


SET PAGE LENGTH, I(-8)M, 
I(M+1)NOD100, PROGRAM‘ DFJPLENG*; 


SET PAGE LENGTH is a blank-level command 
that allows the user to specify the number 
of printed lines per page on a sequential 
device that is to contain printed output. 


as ae aaa aa ) GREER aa 5 Ca aET eR ECAGiCS Bare aaa ee aca 1 
| | DEFAULT] CHECKING| 
| MODE | VALUES | RULES | EXPRESSION | 
4------ 4------- }--------- 4~-----------—---- { 
; <r 1 | | | 
$------ $------- }-~------- $----------------- : 
} <I | 60 | | | 
$------ +------- 4--------- {----------------- { 
| <I {100 | | | 
bf eseneee Pecsosos peep taper ee te ee, J 
the PAGE LENGTH operand is to be 
associated. 
ALTER PHRASE: INPUT, I(-8)M, I(M)NOD1,0, 


LEVEL 1, PROGRAM‘ DFJPIOCS*; 
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INPUT is 
change the device that is assigned as 
standard PLAN input device. 


a command that may be issued to 
the 


1. NOD. This parameter defines the number 
of the device that is to be used for 
PLAN input. The output device is not 
changed. 


ALTER PHRASE: OUTPUT, I(-8)M, I(€M)AO, 
I(M+1)NOD101, LEVEL1, PROGRAM'DFJPIOCS' ; 


OUTPUT is a command that may be used to 
change the device that is assigned as the 
standard PLAN output device. 


1. NOD. This parameter defines the number 
of the device that is to be used for 
PLAN output. The input device is not 
changed. 


4.5.14 SPECIAL PURPOSE OS PHRASES 


ALTER PHRASE: CREATE LOADER 


PROGRAM’ DFJLLIST‘ ; 


ENTRIES, 


CREATE LOADER ENTRIES is a command that 
gives OS PLAN the capability of referencing 
the RAM or LINKPAC areas. 


The general format of this command is: 
CREATE LOADER ENTRIES: (NAME1, ...2.)3 


is a load module name that 
the 


where NAME1,... 
is to be loaded into the partition via 
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LOAD macro and be made available as entry 
points for the execution of any loader 
call. This allows programs in the LINKPAC 
or RAM areas to be objects of a CALL LOCAL. 
The names specified in the LIST must be in 
the JOBLIB PDS or LINKLIB PDS. 


The maximum number of names in the list is 
15% Use of this command destroys any 
entries defined by previous use of the 
command. 


Programs that reference blank COMMON may 
not be operands of this command. 


ALTER PHRASE: 
GRAM *‘DFJCRDIR‘; 


CREATE CORE DIRECTORY, PRO- 


CREATE CORE DIRECTORY is a command that 


allows the user to build an in-core PDS 
directory of names of frequently loaded 
modules. 


CREATE CORE DIRECTORY: (NAME1,...); 
NAME1,... is a 
placed in the in-core PDS directory to 
decrease load time for those modules. The 
names in the list must be entries in the 
PLANLIB PDS. 


Use of this command will replace the pre- 
vious directory. The maximum number of 
entries is 75 names. 


load module name that is 
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This section describes the functions of the 
various PLAN subroutines that are available 
for use by the application programmer. 


Sections 5.1.0 through 5.10.0 list the 
subroutines and their specifications. Sec- 
tions 5.11.0 through 5.11.11 provide the 
details of usage. 


5.1.0 PLAN LOADER SUBROUTINES 


This subroutine allows a user to 
modify the PLAN pop-up list. The 
current program in execution is 
saved for future reentry at the 
next executable statement when an 
asterisk (*) is found in the pop-up 
list. 


LCHEX 


This subroutine allows a user to 
modify the PLAN pop-up list. 
Transfer to PLAN then occurs to 
load the first (top) program 
defined in the pop-up List. 


LEX 


LIST This subroutine allows a user to 
modify the PLAN pop-up list. Proc- 
essing continues at the next 
executable statement in the calling 


program. 


This subroutine allows a user to 
add a program name to the bottom of 
.the PLAN pop-up list. Processing 
continues at the next executable 
statement in the calling program. 


LISTB 


This subroutine breaks the chain of 
returns normally followed within 
PLAN LOCAL processing. 


LNRET 


This subroutine allows a user to 
modify the PLAN pop-up list. The 
top program in the pop-up list is 
loaded and control passes to the 
program. The program must coexist 
in memory with the calling module 
because the calling module will be 
reentered at a later time. The 
program is not loaded if already in 
core. Note that the calling module 
remains in core with the called 
module; this is true of a nest of 
locals as well. 


LOCAL 


subroutine allows the re- 
the last command 


This 
execution of 
processed. 


LREPT 
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5.0.0 PLAN SUBROUTINE SUPPORT 


This subroutine is the normal exit 
from a logic module. It does not 
modify the PLAN pop-up list. It 
exits to PLAN to load and transfer 
to the top program in the pop-up 
load list. If the pop-up list is 
empty and saved statements are not 


LRET 


being executed, a new command is 
processed. If the program execut- 
ing a CALL LRET was called by a 


CALL LOCAL, control is returned to 
the next executable statement after 
the CALL LOCAL. 


5.2.0 PLAN I/O CONTROL 


This subroutine allows redefinition 
of the PLAN system parameters. The 
command input device and diagnostic 
print device may be shifted among 
supported I/O devices. 


rocs 


9.3.0 PLAN ERROR PROCESSING 


The following six subroutines allow appli- 
cation logic modules to generate and proc- 
ess diagnostic messages through the use of 
the PLAN system error processing module 


(PERRS) . The format of the diagnostic 
produced is identical to that produced by 
PLAN. The diagnostic literal is 


user-supplied. 
ERLST This subroutine causes all diagnos- 
tics that are in the PLAN error 
queue file to be printed on the 
PLAN system diagnostic device. 
Processing of the current phrase 
(including programs in pop-up list) 
is terminated. This subroutine 
provides the capability required 
for post-list error processing. 
ERRAT This subroutine interface to the 
PLAN error module PERRS returns to 
the next executable statement in 
the calling program. PLAN will 
load any remaining programs in the 
pop-up list. However, the next 
time that PSCAN is entered, PLAN 
level error recovery is initiated. 
ERRET Processing continues at the next 
executable statement following the 
call to the subroutine. 

ERREX This subroutine interface to the 
PLAN error module PERRS does not 
return to the calling program. 
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PLAN is entered to load any remain-~ 
ing programs in the pop-up list. 


ERROR Processing does not return to the 
calling module and the PLAN level 
error recovery is initiated. 

EWRIT his subroutine allows the user to 


write messages into the PLAN error 
file (file 255, DYNAMIC drive 0) in 
a format acceptable for processing 


by CALL ERLST. 


9.4.0 PERMANENT FILE SUPPORT 


GDATA, 

GDAT1 These subroutines perform the file 
open function for PERMANENT fixed 
size files established outside of 
PLAN. The call places file loca- 
tion pointers in the user-defined 
file control block. 

RDATA, 

RDAT1 These subroutines provide for 
transfer of information from a 
PERMANENT file location on disk to 
memory. Records may contain any 
variable number of 32-bit or 16-bit 
words. 

WDATA, 
WDAT1 These subroutines provide for 


transfer of information from memory 


any desired 


to a PERMANENT file location. 
Records may contain 
number of words. The file 


addressed by the 


is 


number of words 


displacement from the beginning of 


the file. 


5.9.0 DYNAMIC FILE SUPPORT 


FIND, 
FINDL, 
PFND1 ) 

function for DYNAMIC files. 
Ic files are 


defined by 


Disk space is assigned to the 


These subroutines perform the open 
DYNAM- 
established when 
needed (they may be permanent) 
execution-time logic. 


as 


file 


in modular segments as required by 


the file. 
any desired number of 


Transfer is by groups of 
32-bit or 


16-bit words to or from any desired 


displacement within the file. 
may be assigned to 
the 1130) 
Priority may be assigned 


DYNAMIC files 
any of eight 
drives. 


(five on 


PLAN 


to a DYNAMIC file to allow orderly 


release of files 
file space is available. 
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if insufficient 


PFSPC 


RELES, 
PREL1 


READ, 
PRED1 


WRITE, 
PWRT1 
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This subroutine provides the facil- 
ity to request verification of the 
availability of a block of storage 
for assignment to a DYNAMIC file at 
a designated priority. 


These subroutines release space 
held by a DYNAMIC file to the pool 
of available disk space. RELES 
performs the opposite function of 
the FIND routine. 


These subroutines transfer data 


from a DYNAMIC file to memory. 


These subroutines transfer info:rma- 
tion from memory to a DYNAMIC file. 
Space is automatically allocated if 
a write requires more space than 
the current file contains. 


5.6.0 COMMAND RETRIEVAL AND EXECUTION 


INPUT 


PUSH 


This subroutine transfers the 
EBCDIC representation of the last 
command processed and the length of 
the command in characters into 
memory to allow processing or 
printing of the command. 


This subroutine provides the abili- 
ty to execute commands from memory. 


5.7.0 LOGICAL FUNCTIONS 


FALSE 


NDEF 


TRUE 


This subroutine sets a word in 
memory to the value of logical 
FALSE. 


This function subroutine allows 
testing of any location for the 
PLAN logical functions FALSE, TRUE, 
or REAL (nonlogical). 


This subroutine sets a word in 
Memory to the value of logical 
TRUE. 


5.8.0 SORT/MERGE CONTROL 


GMERG 


GSORT 


(OS/DOS only) This subroutine 
forms the initialization functions 
for the PLAN system moclule 
DFJGMRGA. The module issuing the 
CALL GMERG is reentered when the 
merge is completed. 


per- 


(OS/DOS only) This subroutine per- 
forms the initialization functions 
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PSORT 


PMERG 


for the PLAN system modules 
DFJGSRTA and DFJGSRTB. The module 
issuing the CALL GSORT is reentered 
when the sort is complete. 


This subroutine performs the 
initialization functions for the 
PLAN system module PSRTA. It 
causes the managed array to be 
saved and results in a checkpoint 
(CALL LCHEX) exit. The module 
issuing the CALL PSORT is reentered 
when the sort is completed. 


This subroutine performs initiali- 
zation functions for the PLAN sys- 
tem module PMRGA. The module issu- 
ing the CALL PMERG is reentered 
when the merge is completed. 


5.9.0 SEQUENTIAL FILE CONTROL 


PLINP 


PLOUT 


PIOC 


PBUSY 


PSBFA, 
PSBFB, 
PSBFC, 
PSBFD, 
PSBFE 


PDBFA, 
PDBFB, 
PDBFC, 
PDBFD, 
PDBFE 


PBFITR 


PEOF 


This subroutine provides the input 
processing for overlapped, buffered 
transfer from a PLAN-supported 
input device to the system buffer. 


This subroutine provides the output 
processing for buffered, overlapped 
transfer from the system buffer to 
a PLAN-supported output device. 


This function subroutine allows a 
user to test a device status for 
busy. 


This subroutine tests all PLAN 
devices controlled by PLINP and 
PLOUT. PBUSY returns only when 


none are found to be busy. 


These subroutines provide Single- 
buffering assignment (for 1130 
PLAN) for devices specified for use 
by the PLINP and PLOUT routines. 


These subroutines provide double- 
buffering assignment (for 1130 
PLAN) for devices specified for use 
by the PLINP and PLOUT routines. 


This subroutine allows direct 
transfer between PLAN buffers, 
facilitating input followed by out- 
put of the same data where inter- 
vening formatting and/or processing 
is not required. 


This function subroutine allows 
testing of end-of-file conditions 
generated as a result of CALL PLINP 
or CALL PLOUT. 


PpccTL 


PAIN, 
PAOUT 


-PIIN, 


PIoUT 


PFIN, 
PFOUT 


PEOUT 


PHIN 


PHOUT 


PARGO 


PARGI 


GTVAL, 
STVAL 


BREAK 


PPACK 
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This subroutine provides device 
control functions such as carriage 


skipping and spacing and stacker 
selection. 

These subroutines provide for 
transfer from/to the PLAN system 


buffers to/from user-designated 
storage with variable literal (A) 
format control. 


These subroutines provide for 
transfer from/to the PLAN system 
buffers to/from user-designated 
storage with integer (1) format 
control. 

These subroutines provide for 
transfer from/to the PLAN system 
buffers to/from user-designated 
storage with floating-point (F) 


format control. 


This subroutine provides for 
transfer of data from user- 
designated storage to the appropri- 
ate PLAN system buffer in exponen- 
tial floating-point (E) format. 


9.10.0 ARRAY AND DATA MANIPULATION 


This subroutine provides for 
transfer of literal data to memory. 
The literal file is maintained on 
disk by the module PDIAG through 
control of the PLAN command SET 
LITERAL. 


subroutine transfers literal 
PDIAG 


This 
data to a file from memory. 
requires this subroutine. 


This subroutine provides transfer 
Of data from a user array to the 
PLAN communication array. 


This subroutine provides the abili- 
ty to move data lists from the PLAN 


communication array to a user 
array. 
These subroutines allow easy, 


efficient transmission of arrays to 
and from any location in storage. 


This subroutine spreads the four 
bytes of a 32-bit word into the 
low-order position (rightmost eight 
bits) of four words of an integer 
array. 


This subroutine masks the low-order 
byte of an integer word into any 
byte position of a 32-bit character 
array. 
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PUNPK This subroutine moves any byte  PHTOE 
position of a character array into 
the low-order byte position of an 
integer word. The high-order bits 
are set to zero. 


PCOMP This function subroutine performs a PBTST 
logical comparison of one 32-bit 
array with a second array and sets 
the floating-point FORTRAN function 
indicator. 
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This subroutine converts hexadeci- 
mal arrays to EBCDIC arrays. The 
EBCDIC array produced occupies 
twice as many words as the hexa- 
decimal array. 


This subroutine allows for the 
testing or setting of any bit or 
bits (0-31) within a 32-bit word. 
It also provides a test or extract. 
under mask. 
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5.11.0 PLAN SUBROUTINE USE 


This section provides a detailed descrip- 
tion of calling sequences and performance 
characteristics of PLAN system subroutines. 
The calling sequences are shown as FORTRAN 
statements. Use of the subroutines by 
modules programmed in other languages (sym- 
bolic and assembler) must be programmed 
according to the FORTRAN conventions. Spe- 
cific differences in the action/use of 
these routines between various versions of 
PLAN are documented in the appendices of 
this manual. 


5.11.1 PROGRAM LINKAGE ROUTINES 


ce ae a a a A ee en Se IO a cc a 1 


{ LOADER SUBROUTINES 
CALL LIST(N,L) 
CALL LISTB(2,1L) 

LEX(N, L) 

CALL LCHEX(N, L) 

CALL LOCAL(N,L) 

CALL LRET 

CALL LNRET 

CALL LREPT 


WN the count of 32-bit words to move 
L the user list array 


( ie ane AES | 
Q 
E 


| CALL LIST (1,0) 
| CALL LEX (6,ARRAY(6)) 


ee ee 


The subroutines defined below allow a_ user 
to communicate with the PLAN loader and 
manipulate the pop-up list. Each subrou- 
tine in this group is named with an initial 
"L* to indicate its special relationship 
with the PLAN loader. Ever PLAN logic 


Bvery__Eban _1LOgic 
module normally exits to the PLAN loader 
through one of these subroutines. 


The linkage CALL LRET returns directly to 
the PLAN loader without modification to the 
pop-up list. If the pop-up list is not 
empty, the program named at the top of the 
list will be executed next. If the pop-up 
list is empty (0), PSCAN is loaded to 
process a new command. Exit from a module 
via CALL LRET provides a set of modules 
whose linkage sequence is governed by the 
problem description. 


For creating special compile-time con- 
trolled linkages, other loader subroutines 
are useful. In the following examples, 


N is the number of program identification 
words (32-bit words) to be moved to/ 
from the pop-up list. A program name 
occupies two 32-bit words. Thus, a 
list of three program names requires 
that N be defined as 6. N may be an 
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integer constant, or a subscripted or 
nonsubscripted integer variable. 


L is the location of the array in the 
problem program (or communication 
array) that holds the words to be 


moved. 


Positive values of N cause movement from 
array L to the pop-up list. Negative 
values of N cause movement from the pop-up 
list to array L and remove the moved items 
from the pop-up list, If the absolute 
value of N when N is negative is greater 
than the number of 32-bit words in the 
list, a numeric zero is transmitted to 
array L following the last item in the 
list. Zero as a value of N causes no 
movement. If values are moved L(1) becomes 
the top of the pop-up list. Additions push 
the old list down to position (N+1) of the. 
pop-up list. Deletions pull the value at 
(N+1) up to the top. 


When N is’ positive, the input array is 
scanned from end-to-start, accessing and 
placing in the pop-up list a 64-bit word at 
a time. 


If a numeric zero is encountered in bits 
0-31 of the 64-bit word containing a pro- 
gram name, the pop-up list is cleared. If 
the absolute value of N is odd, it is 
incremented by one. 


To avoid reprogramming, parameters N and L 


should be symbolic, equivalenced to com- 
munication array locations. An argument 
list of (1,0) in the following calls 


destroys the current contents of the pop-up 
list whereas (0,0) leaves it unchanged. 


Functions of the subroutine calls are: 
CALL LIST(N,L) manipulates 


list and returns to the next 
following the call. 


the pop-up 
statement 


CALL LISTB(2,L) places a single program 
name at the bottom of the pop-up list and 
returns to the next statement following 
the call. Note that 2 will always be the 
value of N for the LISTB subroutine. 


CALL LEX(N,L) manipulates the load list 
and then loads and branches to the next 
program in the pop-up list. 


CALL LCHEX(N,L) manipulates the pop-up 
list, saves the current program for later 
reentry, then exits to the loader. 
COMMON is not affected. No test is made 
to protect the PLAN communication array 
from overlay by the next module, so the 
module issuing the CALL LCHEX may have to 
save and restore parts Of COMMON if the 
checkpoint load will overlay it. The 
saved program is reentered at the next 
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instruction following the CALL LCHEX 
(N,L) when a left-justified asterisk is 
found in the pop-up list. A checkpoint 
May not be carried beyond phrase boun- 
daries. In other words, if an asterisk 
has not been encountered in the ‘pop-up 
list before the list is emptied (PSCAN is 
reloaded) a PLAN phrase ‘abort (level 
error recovery) is initiated. 


CALL LOCAL(N,L) manipulates 
list, then loads and 
program in the pop-up list. The address 
of the instruction following the CALL 
LOCAL (N,L) is saved for a return from 
the LOCAL program when a CALL LRET is 
issued. Both the local program and the 
calling program will coexist in memory at 
the same time. Additional information on 
the use of local programs is contained in 
the appendices of this manual. 


the pop-up 
enters the next 


CALL LRET is the normal exit from a logic 
module. It does not modify the pop-up 
list. It exits to PLAN to load the 
program named at the top of the pop-up 
list. If the list is empty and_ saved 
statements are not being executed, a new 
command is processed. If the program 
executing a CALL LRET was called by a 
CALL LOCAL, control is returned to the 
calling program at the next executable 
statement following the CALI LOCAL. 


CALL LNRET specifies that a’ normal return 
(CALL LRET) is not anticipated. CALL 
LNRET provides a means of canceling all 
"LOCAL* processing in progress. CALL 
LNRET informs PLAN that the calling 
module will not return to the module that 
called it. A CALL LRET issued by a 
module after a CALL LNRET causes a return 
to the PLAN loader. Any OS/360 module 
containing a CALL LNRET may not be ter- 
minated with a RETURN statement. 


CALL LREPT repeats processing of the 
current command. The pop-up list is not 
cleared by execution of CALL LREPT, but 
the repeated command is processed before 
the programs are loaded. 


The following example (shown with IBM 1130 
control cards) illustrates commands and 
programming that will perform the following 
functions: 
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Step 1 represents the 1130 System FORTRAN 
compilation of program "M0725". 


Step 2 is’ the 
module 
PLAN can only retrieve modules 
core image. 


loading of the compiled 
into core image (residing on disk). 
stored in 


Step 3 is the execution of the PLAN system, 
where program "M0725" is loaded and 
executed first. Program "M0788" is 
executed out of line by the calling of the 
LCHEX (CALL LCHEX(4,PLIST)), which allows 
the user to modify the pop-up list. The 
current program in execution (M0725) is 
saved for future reentry at the next 
executable statement when an asterisk is 
found in the pop-up list. After M0725 is 
reentered, a call of subroutine LEX is 
encountered which will manipulate the pop- 
up list and then load and execute to the 
next program named in the pop-up list. The 
pop-up list will then be loaded with the 


program names PROGA, PROGB, PROGC, and 
PROGD, with PROGA residing on top. 
STEP1 
4/7 JOB 
// FOR 
DIMENSION PLIST (4) 
COMMON L(625), LS(15), M(255) 
EQUIVALENCE (N,M(20)), (ABCD,M(21)) 
DATA PLIST/*MO78*, *8°, ‘°* ‘/ 
CALL LCHEX (4, PLIST) 
CALL LEX (N,ABCD) 
END 
STEP2 
7/ DUP 
*STORECI WS UA M0725 
STEP3 
// XEQ PLAN 
ADD PHRASE: LOAD PROGRAM, I(20)NO0, 


PRO‘ M0725°; 


LOAD PROGRAM, N8 
"PROGD"; 


"PROGA" "PROGB""PROGC" 


(REMAINING PLAN INPUT) 
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5.11.2 DYNAMIC FILE SUPPORT 


Usenet a we Oe a ee ree tga tows ete 1 
|DYNAMIC FILE ROUTINES 

|CALL FIND (ID, NPRI, NALLO, NDR) 
[CALL FINDL(ID, 0, 0, NDR) 

{CALL READ(ID,KDIS, KOUNT, KORE) 
|CALL WRITE (ID, KDIS, KOUNT, KORE) 
{CALL RELES (ID, 0, NSQZ, NDR) 


ID File control block 
NPRI File priority (0,1,2,3,4) 
NALLO Initial allocation requirement 


NDR DYNAMIC drive code (0-7 or 0-4 
the 1130) 
KDIS File displacement 


KOUNT Words (32-bit) to transfer 
KORE User array 
NSQOZ Words not to be released 


a eS SES ORS OS eS I Gee EE eS A a eee oes onde eee 


| 
| 
{ 
| 
| 
| 
| 
| 


Q 


WRITE ARRAY 1-700 AND CHECK 
DIMENSION NA(100),ID(2) 
COMMON L(625),LS(15),CA(510). 
SET FILE CONTROL BLOCK 
ID(1)=27 
OPEN FILE 
CALL FIND (ID,2,700, 3) 
INITIALIZE ARRAY 
DO 5 I=1,100 

5 NACI)=I 
WRITE 7-100 WORD RECORDS 
DO 10 I=1,7 
CALL WRITE (ID, ID(2) ,100, NA) 
UPDATE ARRAY BY 100 
DO 15 J=1,100 

15 NA(J)=NA(J) +100 

10 CONTINUE 
READ BACK 100 WORD GROUPS 
DO 25 I=1,7 
CALL READ (ID, (I-1)*100,100, NA) 
DO 25 J=1,100 
CHECK FOR VALID NUMBER 
IF (NA (J)- (J+ (I-1) *100)) 20,25,20 
ERROR 

20 PAUSE 7 

25 CONTINUE 
RELEASE TOTAL FILE 
CALL RELES(ID,0,0,3) 
RETURN TO PLAN 
CALL LRET 


Q QO Qo a a 


Qa 067 


cere cee a re cee OE cere SO capes mes SS ee ee SE ces ge SS ED re SRS ames cen SORE coed ST EE coe eS ES con SE EE ees A ees SS ee es SS ee eee SD 
Qo A QO 
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The subroutines defined below provide the 
DYNAMIC support for processing variable- 
length, discretely addressable disk data 
sets. All parameters associated with for- 
mation of the data sets are definable at 
execution time rather than at compile time. 
Each word in the file is discretely 
addressable. This allows disk to be 
treated as an out-of-core array. 
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The physical location of a data set is made 
available during execution by the following 
FORTRAN (or equivalent) call: 


CALL FIND(ID,NPRI,NALLO, NDR) 


The parameters of the call have the follow- 
ing meanings: 


ID identifies the first of a two-word file 


control block. Each data set (file) has a 
separate file control block. If the file 
control block is in COMMON (communication 
array), one CALL FIND can satisfy a_ series 
Of programs and result in a saving of disk 
access time. If the file control block is 
not in COMMON, each program must issue its 
own CALL FIND for the file. The value 
stored in ID(1) by the calling program must 
be an integer from 1 to 255. This is the 
DYNAMIC file number. DYNAMIC file number 
255 on DYNAMIC drive 0 is used by PLAN for 
error message processing. DYNAMIC files 
201 to 255 on DYNAMIC drive 0 are reserved 
for PLAN utilities. The remaining numbers 
(1-200) can be used to uniquely identify 
user's DYNAMIC files. After the CALL FIND 
has been executed, ID(1) contains a coded 
pointer to the beginning of the data _ set, 
and ID(2) contains the current file length. 
IpD(2) contains a zero if this is a newly 
established file. 


DYNAMIC files are not expected to reside on 
more than one DYNAMIC drive. The program- 
mer May create a sequence of data sets 
crossing DYNAMIC file boundaries, assuming 
that more than one DYNAMIC drive is 
available. 


FIND treats ID(1) modulo 256. This means 
that a FIND issued to a file control block, 
that shows an open or closed condition, 
will result in the true length of the 
DYNAMIC (current status) being placed in 
ID(2). The remaining parameters for CALL 
FIND are used only at the time a new 
DYNAMIC file is opened but they must always 
be present. 


NPRI assigns a retention priority to the 
DYNAMIC file. Zero sets the priority equal 
to the level of the command currently being 
processed. Priority 1 indicates that the 
DYNAMIC files cannot be automatically 
released by the system. Priorities 2, 3, 
and 4 are successively inferior levels of 
temporary data and are automatically 
released whenever a command of higher level 
(lower-numbered) is processed. 


A DYNAMIC file retains the priority defined 
in the initial CALL FIND and is’ unchanged 


regardless of the specification in subse- 
quent CALL FIND‘s, until released (CALL 
RELES). 
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PLAN will automatically release lower- 
priority files to create space for higher- 
priority files if insufficient space is 
available for the required higher-priority 
file. If a file is automatically released, 
the file control blocks opened for that 
file are not marked as closed. 


NALLO, when given as a value other than 0, 
is used to optimize file space allocation. 
Normally, space is allocated to aée file 
incrementally, only as needed. It is more 
advantageous to allocate space for an 
entire DYNAMIC file at one time if the 
requirement is known. NALLO provides an 
estimate of the expected file size and is 
used to calculate the number of words in 
the initial allocation according to the 
following formula: 


NWA = ((NALLO-1)/NSA+1) * NSA 


number of 32-bit words 
actually allocated. NSA is the number of 
PLAN words ina standard unit allocation 
(see Appendix A, B, or C for discussions of 
this parameter). 


where NWA is the 


If the initial allocation request is for 
1000 32-bit words and the standard unit 
allocation is NSA=628, then 1256 words 


would actually be allocated. 


NALLO is 
exists. 
of the 


ignored if the file already 
NALLO has no effect on the value 
current file size maintained in 
ID(2). NALLO is ignored in incremental 
allocations. Each additional allocation 
includes only one standard unit allocation. 


NDR defines the DYNAMIC drive on which the 
DYNAMIC file is to reside. The parameter 
May range from 0 to 7, except as limited by 
the hardware configuration. This parameter 
specifies a logical drive in the 1130 
system and is limited to the range of 0-4. 
In the 1130, digits to the left of the 
units digit in the indicator are used _ for 
verification of pack label identification 
as defined in Appendix A (8.6.0) of this 
manual. 


The FINDL subroutine provides a check for 
the current existence of a file. Space. is 
not allocated for the file if it does not 
exist. If the file does exist, the file is 
opened and the current true file size is 
placed in ID(2). If the file does not 
exist, the file is not opened and ID(2) is 
set to zero. If an error is found (for 
example, the drive code is invalid), the 
file is not opened and ID(2) is set to an 
error code as defined for DYNAMIC files 
near the end of this’ section. In all 
cases, control is returned to the calling 
program. 
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The RELES subroutine releases space held by 
a PLAN dynamic file to the pool of avail-~ 
able disk space. RELES performs the oppo- 
site function of the FIND subroutine. 


CALL RELES (ID,0,NSQZ,NDR) 


The CALL RELES parameters ID and NDR have 
the same meaning as defined for the CALL 
FIND. Use of this call prevents the tmnec- 
essary accumulation of temporary data. 
Obsolete files that are not released may 
degrade performance by forcing long seeks. 


If NSQZ is zero, the file control block is 
closed and ID(2) is not ailitered. NSQZ 
provides for partially releasing space 
allocated to a DYNAMIC file, that is, the 
first NSQZ words of the file are retained. 
In actuality, if NSQZ is other than 0, the 
file control block is not closed, The 
current file length indicators are updated 
when necessary and disk space is released 
to the available pool whenever complete 
allocation units are found to be free. The 
true file size is set to the value of NSQZ 
if it is greater than NSQZ. On drives 
other than 0, priority 1 files are released 
only by action (CALL RELES) of the program- 
mer (logic module). All files on DYNAMIC 
drive 0 are released when a level 1 command 
is processed. Therefore, permanent DYNAMIC 
files may not reside on DYNAMIC drive 0. 


On DYNAMIC drive 0, all DYNAMIC files 
(including priority 1 files) are released 
automatically when a level 1 PLAN statement 
is processed. Logical files of priorities 
2, 3, and 4 on other DYNAMIC drives are 
automatically released when a higher-level 
phrase is processed, but priority 1 files 
must be released by CALL RELES. 


Automatic release of files with a priority 
less than 1 is accomplished whenever a 
command with a higher level (lower- 


numbered) than the file priority is proc- 
essed. Thus, a level 1 command results in 
release of all files with a priority of 2, 
3, or 4; level 2 commands result in release 
of files with a priority of 3 and 4; level 
3 commands result in release of files with 
a priority of 4. Open file control blocks 
are not closed. A further attempt to 
process a released file results in a phrase 
abort and PLAN error recovery is initiated. 
The automatic release function is also 
invoked if the DYNAMIC drive is filled and 
a request for space for a higher-priority 
file is generated from the WRITE 
subroutine. 


The CALL RELES function should be the last 
file function executed for any file whose 
control block is not in COMMON and whose 
data has no future use. 
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Transfer of data from memory to the DYNAMIC 
file is accomplished with a CALL WRITE. 
Transfer from the DYNAMIC file is accomp- 
lished with CALL READ. 


CALL READ (ID,KDIS, KOUNT, ARRAY) 
CALL WRITE (CID, KDIS, KOUNT, ARRAY)- 


ID is the first word of the file control 
block as defined for the CALL FIND. A 
coded pointer to the DYNAMIC file is set in 
ID(1) by the FIND routine. The user must 
not alter this word. For the READ/WRITE to 
be successfully executed the file control 
block must show a properly opened file 
(ID(1)>256). 


KDIS 
the beginning of the file 
transfer is to take place. 
for the first word in the file is zero. 
Therefore, the value for kKDIS is always 
(N-1), where N represents the number of the 
first word to transfer. 


is the number of 32-bit words beyond 
at/to which 
The KDIS value 


KOUNT is the number of 32-bit words to be 
transferred with this READ/WRITE operation. 
On a CALL WRITE, ID(2) will be set to KDIS 
+ KOUNT if KDIS + KOUNT is greater than the 
current ID(2). This action will also cause 
the true file size (as maintained in the 
file on disk) to be updated if this WRITE 
is causing an expansion to the true file 
size. This update may be eliminated by the 
user if he writes a word to the end of the 
desired file at the beginning of the file 
write sequence. 


ARRAY is the location in the user's program 
or in the communication array into which 
the data is to be read or from which the 
data will be written. Data transfer starts 
at ARRAY(1) and continues through ARRAY 
(KOUNT) . Transfer continues from KDIS 
through KDIS + KOUNT - 1 on disk. 


The FIND and WRITE subroutines maintain an 
updated count of the length of the file in 
PLAN words. An end-of-file (EOF) will be 
detected on CALL READ if KDIS + KOUNT is 
greater than ID(2) (second word of the file 
control block) or greater than the true 
file size. The condition is indicated by 
setting ID(1) to the file number (ID(1) 
<256). The following FORTRAN statement 
provides a test for the condition: 


IF (I1D(1)-256) 1,1,2 


Statement 1 is executed if the file is 
closed as defined above. Statement 2 is 
executed if a successful READ operation 
occurs. 


The preclosing of files (EOF) can also 
occur on CALL WRITE. The WRITE routine 
causes physical storage to be incrementally 
assigned to the DYNAMIC file as needed 
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during execution. If storage cannot be 
allocated to provide the required file 
space, even by releasing a lower-priority 


file, an end-of-file (EOF) is detected on 


WRITE. 


Any EOF condition detected is indicated by 
setting ID(1) to its original value, in 
effect, closing the file. If an attempt is 
made to read or write a closed file, the 
READ/WRITE routine will generate an EOF 
diagnostic, terminate processing of the 
current statement, initiate level error 
recovery, and load PSCAN to process the 
next PLAN statement. The test listed above 
can be used to prevent an unplanned 
termination. 


If a CALL FIND is subsequently executed on 
a file control block that has been closed 
because of EOF detection, the file will be 
reopened and the current available length 


of the file will be placed in ID(2). If 
the EOF condition resulted from a CALL 
WRITE, the subsequent CALL FIND results in 


a file length indication equal to that 
which existed before the CALL WRITE that 
precipitated the EOF condition. 


a a ne 1 


{TEST DYNAMIC FILE SPACE AVAILABILITY 


CALL PFSPC (0,NPRI,NALLO, NDR) 


| 

| 

{ Oo Indicates a reserved parameter 
| NPRI Priority at which space 

| is desired 

‘| NALLO Location for available space 

| indicator 

| DYNAMIC drive on which space is 
| desired 


SET PRIORITY 

NPRI=4 

FIND SPACE AT THIS PRIORITY 
1 CALL PFSPC (0,NPRI,KT,2) 

IS 2950 WORD AVAILABLE 

IF (KT-2950) 5,5,15 

SET TO HIGHER PRIORITY 
5 NPRI=NPRI-1 

ARE ALL PRIORITIES CHECKED 

IF (NPRI) 10,10,1 

EXIT AND TERMINATE COMMAND 
10 CALL LEX (1,0) 

OPEN 2950 WORD FILE AT LOW PRIORITY 
15 ID(1)=2 

CALL FIND (ID, NPRI,2950,2) 


oO aA aA hea AA A 
an ei es SU cee eee ee ee cee ee es eee eee meee eee cee oie ee cee eet eee ee Oe cee ee eee cs oes ee 
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A test may be made at any time to determine 
the space available for a DYNAMIC file at 
any given priority. If the space available 
is greater than the maximum size of a PLAN 
file, the result is set to the maximum 
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sizeof a DYNAMIC file. The test is accom- 
plished with a call to the PFSPC 
subroutine. 


CALL PFSPC(0,NPRI,NALLO, NDR) 


NPRI defines the priority of the file on 
DYNAMIC drive NDR for which the available 
space is desired. If NPRI is 4, NALLOC is 
set equal to the total number of 32-bit 
words (up to a maximum file size) currently 
unassigned to any PLAN file. If NPRI is 1, 
2, or 3, NALLO is set equal to the unas- 
signed file space plus any space currently 
assigned to any lower-priority files. If 
NPRI is 0, the level of the current command 
will be assumed, and processing continues 
as outlined above. A zero will be placed 
in NALLO if any error is detected by PFSPC. 


PLAN procedures for DYNAMIC file errors are 
invoked on the basis of the DYNAMIC FILE 
ERROR INDICATOR (see "PLAN JOB" 4.5.4). 


The following exceptional conditions can be 
detected by the DYNAMIC file subroutines. 


0. An ID argument specifying an 
unopened file control block on CALL 
READ or CALL WRITE. 


1. KDIS + KOUNT greater than ID(2) or 
true file size on CALL READ. 


2. An invalid NDR or ID argument on 
CALL FIND or RELES. 


3. An invalid ID argument on CALL READ 
- or WRITE. 


4. Invalid KDIS or KOUNT argument on 
CALL READ or WRITE. 


5. DYNAMIC drive not available. 


6. Insufficient space for allocation 
on CALL FIND or WRITE. 


7. Reserved. 


8. (1130 only) Pack ID not equal on 
validity check. 
9. (1130 only) PFIND not in PLAN 
library. 
If the DFI indicator in the PLAN JOB 
command is used, conditions 1-9 in the 


above list result in closing the file 
control block and a negative number is 
stored in ID(2). The negative number is an 
integer (the absolute value of which is 
shown in the above list) that, when added 
to 120, corresponds to a diagnostic number 
that is produced as a result of the error 
when in the immediate mode. 
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Condition 0 when encountered always results 
in a PLAN phrase abort following generation 
of PLAN diagnostic DFJ120. 


The example shown below illustrates logic 
of a check that should be programmed fol- 
lowing each CALL WRITE if optional mode of 
operation is selected in which the DYNAMIC 
FILE ERROR INDICATOR is on. 


EQUIVALENCE (ID2, ID(2)) 
c WRITE A RECORD 
CALL WRITE (ID,KDIS, KOUNT, ARRAY) 
c DID WRITE CLOSE THE FILE 
IF (ID-256) 3,3,30 
Cc SELECT ERROR TYPE - IS EOF ON 
3 IF (ID2) 5,35,35 
5 KD2=-ID2 
GO TO (10,15,20,25, 30) ,KD2 
Cc LOGICAL END OF FILE 
10 CONTINUE 
e 
e 
e@ 
15 INVALID FIND/RELES PROCESSING 
e 
e 
e 
c INVALID READ/WRITE ERROR PROCESSING 
20 CONTINUE 
e 
6 
e 
c NEGATIVE KDIS/KOUNT ERROR PROCESSING 
25 CONTINUE 
® 
e 
@ 
C (1130 ONLY) DYNAMIC DRIVE AVAILABLE 
30 CONTINUE 
e 
e 
@ 
Cc EOF PROCESSING 
35 CONTINUE 


The above files are referred to as PLAN 
DYNAMIC files. The following points sum- 
marize the characteristics of these files: 


1. A DYNAMIC file is established only 
when program logic determines’ the 
file is required. 


2. A DYNAMIC file is assigned physical 
disk space in modular blocks only 
when the space is required. 


3. Every position (32-bit word) within 
the DYNAMIC file is discretely 


addressable. This allows disk to 
be treated as an extension of 
memory. 
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5.11.3 PERMANENT FILE SUPPORT 


poor nnn nn -- + - 
| PERMANENT FILE ROUTINES 


{CALL GDATA (ID,NAME, LR, NDR) 
[CALL RDATA (ID,KDIS, KOUNT, KORE) 
{CALL WDATA (ID,KDIS, KOUNT, KORE) 


ID File control block 

File name (EBCDIC) 

LR Physical record length in bytes 
PERMANENT drive number 

Record displacement in file 
Record length 

User array 


ee as mS CET OES RED OG A a FE RED STC AE ETS HS a A ED a AA ED ED ETE A SD et AE AN CEN AES 


eee et) 


7 ice 
; 
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DIMENSION ID(2),A(2) ,W(100) 
COMMON L(625) ,LS(15)... 
EQUIVALENCE (ID (2), ID2) 
DATA A/*NAME*,‘*F*/ 
FILE NUMBER 1 
ID(1)=1 
OPEN FILE 
CALL GDATA(ID,A,I,0) 
ZERO ARRAY 
DO 5 I=1,100 
5 W(I)=0. 
READ 1ST: WORD 
CALL RDATA (ID,0,1,W) 
IS WORD ZERO 
IF(W(1))8,25,8 
WRITE FILE WORDS TO ZERO 
8 KT=100 
9 W(1)=0. 
DO 20 I=1,1D2,100 
IS PARTIAL WRITE RQD 
IF (ID(2)-I1+1-KT) 10,15,15 
10 KT=ID(2) -I+1 
15 CALL WDATA(CID,I-1, KT, W) 
20 CONTINUE 
25 CONTINUE 


Qa a A 


Q 
ee eee 
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A second type of direct access file support 
is provided by PLAN subroutines. This 
class of support is designed for files 
established outside of PLAN. The file is 
fixed-size and is permanent in terms of the 
ability to establish or release the file as 
a result of program logic within a PLAN 
module. Characteristics of these files and 
the procedures for establishing them are 
closely dependent upon the monitor or 
operating system in control. More specific 
restrictions or capabilities are outlined 
in the appendices of this manual. 


The subroutines to provide this support are 
listed below. The subroutine arguments are 
the same as defined above for the PLAN 
DYNAMIC files. The calling sequence is: 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


CALL GDATA (ID,NAME,LR,NDR) 


CALL GDATA performs functions for the 
PERMANENT file that CALL FIND does for the 
DYNAMIC file, except that no disk space is 
allocated. 

The parameters of the calls listed above 
have the following meaning: 


ID is the first word of the two-word file 
control block. Each file to be referenced 
must have its own file control block. If 
the file control block is in COMMON (the 
communication array), one CALL GDATA can 
Satisfy a series of programs and result in 
a saving of disk access time. If the file 
control block is not in COMMON, each pro- 
gram must issue its own CALL GDATA for the 
file. The value stored in ID(1) by the 
calling program must be an integer from 
1-255. This is the PERMANENT file number. 
After the CALL GDATA has been executed, 
ID(1) contains a coded pointer to the data 
set, and ID(2) contains the file length in 
PLAN words. 


NAME, is an eight-character (64-bit) file 
name left-justified and padded with blanks. 
On the 1130, only the first five characters 
are significant. On DOS, only the first 
seven characters are Significant. NAME is 
unused under 0OS/360 PLAN but must be pro- 
vided by JCL (see OS _ Problem  Lanquage 
Analyzer (PLAN) Operations Manual H20- 


0596). If the length of the file name is 
less than eight characters the remaining 
characters must be padded with blanks. 
Additional information on procedures for 


this action is contained in the appropriate 
appendix under “PERMANENT File Support". 


An automatic equivalence between NAME and 
the file number in ID(1) is implied, and no 
further equivalencing is required, except 
as defined in Appendices B and C. The file 
number must be specified in ID(1) even 
though the file is identified by name. 
Example: 


DIMENSION NAME(2), ID(2) 
DATA NAME/‘ DATA‘ ,‘F‘/ 
ID(1)=25 

CALL GDATA (ID,NAME,LR,0) 


The above defines PERMANENT file 25, 
is named DATAF on PERMANENT drive 0 if 


which 


LR contains the physical length in bytes as 
a fixed-point integer after CALL GDATA has 
been executed. On 1130 PLAN this value is 
a constant 640 (320 1130 words). 


The file size determined when GDATA is 
called represents the total file size; not 
just the portion that has been written. 
Therefore, the user should implement a 
convention (for example, storing the true 
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file size in the first word of the file) 
for maintaining the true file size if it is 
necessary at any time to determine how much 
data has been written within the extent 
limits of the file. 


NDR contains the number of the PERMANENT 
drive on which the file exists, and may 
range from 0-7. 


CALL RDATA (ID,KDIS, KOUNT, ARRAY) 
CALL WDATA (ID, KDIS, KOUNT, ARRAY) 


KDIS is the number of 32-bit words beyond 
the beginning of the file at/to which 
transfer is to take place. The KDIS value 
for the first word in the file is zero. 
Therefore, the value for kKDIS is always 
(N-1), where N represents the sequence 
within the file of the first word to be 
transferred. 


the number of 32-bit words to be 
RDATA/WDATA opera- 


KOUNT is 
transferred with this 


tion. On a CALL WRITE ID(2) will be set 
equal to KDIS + KOUNT if KDIS + KOUNT is 
greater than the current ID(2). Any 


attempt to issue a RDATA/WDATA outside the 
true file size will result in the file 
control block being marked as closed. 


ARRAY is the user's data array to/from 
which data is to be transferred from/to the 
file. 


PLAN procedures for PERMANENT file errors 
are invoked on the basis of the PERMANENT 
FILE ERROR INDICATOR (see “PLAN JOB" 
4.5.4). 


The following exceptional conditions can be 
detected by the PERMANENT file support 
subroutines. 


1. An invalid NDR or ID argument on 
CALL GDATA. 


2. An invalid file ID argument on CALL 
RDATA or WDATA. 


3. Negative KDIS or KOUNT arguments on 
CALL RDATA or WDATA. 


4. An ID argument specifying an 
unopened file control block on CALL 
RDATA or WDATA. 


5. KDIS + KOUNT greater than ID(2) of 
the file control block or the actu- 
al file size. 


In the normal mode of operation, cases 1 
through 4 are considered phrase abort con- 
ditions and cause a diagnostic message to 
be issued and PLAN level recovery proce- 
dures invoked. 
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Case 5 is considered a normal program event 
(EOF), and the only action ever taken is to 
mark the file control block as_ closed. 
ID(1) is reset to the file number to mark 
the file as closed. 


If the PERMANENT file error indicator in 
Switch Word 13 is on, cases 1 through 3 
cause a value of -1 to -3, respectively, to 
be placed in ID(2) of the file control 
block, and ID(1) is reset to the file 
number (the file control block is marked as 
closed). 

abort 


case 4 always causes a 


condition. 


phrase 


5.11.4 ONE-WORD INTEGER SUPPORT 


A AS ES A SS SS A ND SD SE SS SS SLY SE AE SS YS ND MAN DE NY 


{CALL PFND1(ID,NPRI,NALLO, NDR) 
|CALL PRED1(ID,KDIS,KOUNT, ARRAY) 
{CALL PWRT1(ID,KDIS,KOUNT, ARRAY) 
{CALL PRELI(ID,0,NSQZ,NDR) 

{CALL GDAT1(ID,NAME,LR,NDR) 
{CALL RDAT1(ID,KDIS,KOUNT, ARRAY) 
{CALL WDAT1(ID,KDIS,KOUNT, ARRAY) 


that must be located on an even 
boundary 

File priority 

NALLO Initial allocation requirement 
NDR Logical drive number 
Displacement within the file 
KOUNT Number of words to transfer 
ARRAY User's data array 

Number of words to not release 
File name 

LR Record length in bytes 


1 
| 
| 
| 
| 
| 
| 
{ 
| 
ID Two-word file control block | 
{ 
| 
| 
{ 
| 
| 
| 
| 
| 
| 
| 
{ 


ae Se eee eee ees 
Zz 
n 
10 
N 


|Samples of use of these commands can be 
|drawn from the blocks “DYNAMIC File 
|Support" and “PERMANENT File Support" 
Jif the following name substitutions are 
|made: 


FIND to PFND1 
READ to PRED1 
WRITE to PWRT1 
RELES to PREL1 
GDATA to GDAT1 
RDATA to RDAT1 
WDATA to WDAT1 


FO ce cree ee ee eee eer eee 


The one-word (16-bit) integer option of 
FORTRAN and other nonstandard storage 


options are supported by PLAN direct 
access file routines. Subroutines 
PRED1, RDAT1, PWRT1, WDATI1, PFND1, 


PREL1, and GDAT1 function with one-word 
integer data in a manner identical to 
READ, RDATA, WRITE, WDATA,. FIND, RELES, 


15 SEPTEMBER 1969 


and GDATA with ASA standard (32-bit) 
integer. The values of KDIS and KOUNT 
are given as 16-bit word counts. The 
file length count (ID(2)) is maintained 
as a 16-bit word count. Conversions for 
odd-word counts and odd boundaries in 
one-word integer arrays are automatic. 
Note that the maximum actual file size 
that may be processed with one-wora 
integer support is one-half the number 
of machine words that are attainable 
with the 32-bit support. 


The file control block is organized in 
the same manner as defined for the 
"DYNAMIC File Support" and “PERMANENT 
File Support" and must be on an even 
word boundary. The equivalences between 
standard ASA and one-word integer sup- 
port are shown in the following diagram: 


STANDARD ASA 





ONE-WORD SUPPORT ON System/360 


ae cme ames re ar ame owe cmap we a AA A cm IY 


a: nae = 
| tD(1) | rD(2) | DCs) | DCH) | 


ee ane —1_—......_-—- L— ——————J 
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5.11.5 UTILITY SUBROUTINES 


[ LOGICAL TEST FACILITY 
IF (NDEF(ARG)) 1,2,3 
CALL TRUE(ARG) 

CALL FALSE(ARG) 


ARG User word 
1 FALSE exit 
2 TRUE exit 
3 REAL exit 


DIMENSION A(3) 
Cc SET A(3) REAL 
A(3) = 0 
Cc SET A(2) TRUE 
CALL TRUE (A(2)) 
Cc SET A(1) FALSE 
CALL FALSE (A) 
Cc TEST, FALSE, TRUE, REAL 
DO 6 I=1,3 
IF (NDEF(A(T))) 1,2,3 
1 J=1 
GO TO 4 
2 J=2 
GO TO 4 
3 J=3 
4 IF(I-J) 5,6,5 
TEST ERROR 
5 PAUSE 5 
6 CONTINUE 


ces ee aren cen SEO NS cae OS GD ED SO ND a SEN ge ES epee ee ees Sol cee ees gees mt ces eee anh ome ol 


NDEF(ARG) is an arithmetic function that 
allows testing of any location for the PLAN 
logical functions TRUE, FALSE, or REAL. 
Example: 


IF (NDEF(ARG)) 1,2,3 


1. Statement 1 will be executed next 
i.£ ARG is FALSE (7FFFFFFF 
Hexadecimal). 


2. Statement 2 will be executed next 
if ARG is TRUE (80000000 
Hexadecimal). 


3. Statement 3 will be executed next 
if ARG is anything else. 


The value of ARG is unchanged by execution 
of the NDEF function. 


CALL TRUE(ARG) is a subroutine that sets 
ARG to the value of logical TRUE. 


CALL FALSE(ARG) is a subroutine that sets 


ARG to the value of logical FALSE. 
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Wy net, ee A ee St Sie cae cane i aE OO a Re ae” Ge 1 
| CURRENT COMMAND RETRIEVAL ] 


[CALL INPUT (N, ARRAY) 
]N Size of user array in 32-bit words | 
|ARRAY Array in which to store command 
| image 


{ 

i DIMENSION A(114),IA(1) 

| COMMON L(625),LS(15) 

| EQUIVALENCE (A(1),IA(1),1IA1) 
| CALL PSBFA(100) 

| e 

| e 

| e 

jc READ PHRASE 

| CALL INPUT (114,A) 

jc PRINT PHRASE IMAGE 

| NWDS = (IA1+7) /4 

| DO 10 I=2,NWDS, 30 

| CALL PAOUT(100,1,120,A(TI)) 
| 10 CALL PLOUT(100) 


bee eee, SE ce: SE cogs SOMONE Ce GOED GUNNS eee SS es tee eee ambhts eee os 


CALL INPUT(N,ARRAY) is a subroutine that 
writes into memory the EBCDIC representa- 
tion of the last PLAN command processed and 
the length of the command in characters to 
allow 
command. 


ARRAY is the name of the array that will 
contain the image in A4 format at the end 
of execution of the input subroutine. N is 
the length of ARRAY in 32-bit words. ARRAY 
(1) is set to the total number of charac- 
ters (fixed-point) in the statement. The 
number of characters placed in memory 


equals the length of the statement unless 
the statement is greater than 4 * (N-‘L) 
characters. The maximum number of charac- 


ters to be read is 4*(N-1). Any unused 
positions in the array are set to blank but 
are not counted. 


CALL PUSH(LITL) 
LITL PLAN literal representing the 
command to execute 


--- (27)"DUMP ‘... 


CALL PUSH(LITL) allows a user to call for 
execution of a command from within a user- 
written program module. LITL is a pointer 
to the character count of a PLAN literal. 
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The literal is a PLAN statement minus the 
semicolon with at least one blank following 
to provide space for insertion of the 
semicolon. The PUSH subroutine replaces 
the blank with a semicolon and links to 
PSCAN to execute the phrase. The module 
issuing the CALL PUSH is not reentered. 
The pop-up list is not cleared. 


i a a a ae a a ne rn ee ea oe ee ee ne ee 1 


r 
{LITERAL FILE MAINTENANCE 


| 

REDEEM oe pmtre aet nT el Se RIE Mi yas Ree Ne ee J 
J|CALL PHIN(ID,1,A) | 
{CALL PHOUT(ID,I,A) | 
I | 
| ID GDATA open file control block | 
| I Literal identification number | 
| iaA Array containing PLAN literal | 
Be eee 7 
| ADD PHRASE: LITERAL, (5)*TEST PHIN AND | 
| PHOUT" ; | 
| LITERAL; | 
| : l 
l > | 
| | 
| DIMENSION A(20), FNAME(2) ,ID(2) | 
| COMMON L(625),LS(15) ,CA(510) | 
| DATA FNAME/‘FNAM‘, °E'/ | 
| : | 
| : | 
| . | 
| ID(1) = 5 | 
q CALL GDATA(NFCB, FNAME, KT, 2) | 
[c WRITE LITERAL TO FILE | 
| CALL PHOUT (ID,12,CA(5) ) | 
jc RETRIEVE LITERAL { 
| CALL PHIN (ID,12,A) | 
|c FIND WORDS IN LITERAL | 
{ KT = (CA(5)+#+3)74 | 
jc COMPARE IN-OUT LITERAL | 
| DO 5 I=1,KT | 
| IF (CA(I+5) -A(I+1)) 4,5,4 | 
| 4& PAUSE { 
| 5 CONTINUE | 
| a4 | 
[ . | 
| : | 
a lh a a a a 5 a la J 
CALL PHIN(ID,I,A) is a subroutine’ that 
retrieves a PLAN literal or table from a 
PLAN PERMANENT file and places it in 
memory, Starting at location A. Literal 


number I in the file defined by the open 
GDATA file control block ID is a PLAN 
literal whose length in characters (bytes) 
is placed in A(i). The text of the literal 
is placed in A(2) to A(2+(N-1)/4), where n 
is the length placed in A(1). Literals or 
tables retrieved by PHIN must have heen 
written using PHOUT or the SET LITERAL 
command. 


Following execution of the CALL PHIN, A(1) 
will contain an integer value as defined in 
the table shown below: 
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INTEGER 
IN A(1) MEANING 

+N The number of characters in the 
literal. 

0 The file control block ID was 
found not to be open. 

-1 The file is not a valid literal 
file. 

-2 The requested literal number is 
greater than any literal contained 
in the file. 

-3 The requested literal number is 


not contained within the literal 


file. 


CALL PHOUT(ID,I,A) is a subroutine that 
adds PLAN literals or tables to a PLAN 
PERMANENT file. The literal number is I 
and the character count (bytes) followed by 
the literal (table) is located in memory at 
location A. The file to which the literal 
is to be added is defined by the open GDATA 
file control block located at ID. The SET 
LITERAL command invokes execution of the 
PDIAG module, which in turn calis PHOUT. 


mg aah a amen a aie oe SE I A RRS RS CCE ES merece em cme i | 
{MODIFY STANDARD PLAN DEVICES | 


| ----------------------------------------- { 
{CALL I0cS (INPUT,LIST) 


Device number for standard PLAN 
input device 
Device number for standard PLAN 
output device 


a a a a PE A ES OA SE ON Sa TR PSPC i ARAN SA ED ED I A ED AES SO ce SS 


MODIFY INPUT DEVICE 

CALL I0cS (3,0) 

MODIFY OUTPUT DEVICE 

CALL Iocs (0,102) 

MODIFY INPUT AND OUTPUT DEVICE 
CALL IOCS (2,101) 


oe ee ee ee 
Qa a a 


CALL I0CS (INPUT,LIST) is a subroutine that 
allows a logic module to alter the PLAN 
statement input device and diagnostic list 
device. All parameters are in the fixed- 
point mode. A value of zero for either 
parameter does not alter the existing 
value. Note valid device parameters for 
each PLAN system are listed in the appro- 
priate appendix. A value of 0 for NOD for 
the sequential I/O routine specifies the 
PLAN input device, and 100 specifies the 
current PLAN output device. 
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5.11.6 ERROR INTERFACE SUBROUTINES 


CALL ERROR(N1,N2,LIT) 
CALL ERREX(N1,N2,LIT) 
CALL ERRET(N1,N2,LIT) 
CALL ERRAT(N1,N2,LIT) 


| 
| 
| 
| 
| 
| Ni Error number 

| N2 Error code 

| LIT PLAN literal containing 
| diagnostic text 

{ADD PHRASE: 
| TEST; 


TEST, (25)*TEST DIAGNOSTIC* 


me 


| e 

| e 

| e 

| COMMON L(625) ,LS(15) ,M(100) 

Bs TERMINATE PHRASE AND MODULE 

| CALL ERROR (123,N,M(25)) 

{Cc TERMINATE MODULE 

{ CALL ERREX (M, 27,0) 

jc GENERATE DIAGNOSTIC AND RETURN 
| CALL ERRET (1,2,M(25)) 

|c TERMINATE PHRASE BUT NOT MODULE 
| CALL ERRAT (105,0,0) 

L 


CALL ERROR/ERREX/ERRET/ERRAT(N1,N2,LIT) are 
subroutines that access the system error 
processor to produce error diagnostics. In 
each call, Ni and N2 are _ user-selected 
identification numbers that may be used for 
diagnostic messages. LIT is the word con- 
taining the character count of a PLAN 
literal that is to make up the diagnostic 


message. The literal text in PLAN literal 
format is found in LIT(2) to LIT(n), where 
n equals the character count minus. one 


divided by four plus two. 


The ERROR subroutine aborts the current 
PLAN statement (initiates PLAN level error 
recovery); 


ERREX returns to the PLAN loader to execute 
the next program in the pop-up list; 


ERRET returns to the next statement in the 
calling program; 


ERRAT returns to the next statement in the 
calling program, processes the remaining 
programs in the pop-up list, and effects 
PLAN level error recovery the next time 
that the pop-up list is found empty. Note 
that a phrase abort means PLAN level error 
recovery procedures are initiated. These 
calls, when necessary, save the calling 
module, load the error processing module, 
and restore the calling module if saved. 
The calling module, therefore, does not 
need the output device routine and so is 
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more economical of memory utilization than 
inline error coding. 


On the 1130, if COMMON in the calling 
module is larger than the maximum protected 
by PLAN, the programmer must use a PLAN 
file to save and restore the additional 
COMMON if error processing is in the imme- 
diate mode, if a user error module is 
required to process the diagnostics, or if 
the diagnostics will cause an overflow of 
the PLAN error stack. (Note that overflow 
of the PLAN error stack is unpredictable to 
the programmer. ) 


Line 1 of the diagnostic locates the error 
and identifies it with the programmer's 
catalog codes Ni and N2. Underlined por- 


tions of the message are variable. The 
literal text of the last command processed 
precedes all diagnostics resulting from the 
phrase if the long-form diagnostic is 
selected (see "Switch Words", 4.3.21). 


The format and meaning of the diagnostic 
produced by the routines defined above are 
as follows: 


DFJ000 001-100 
101-199 
201-299 
301-399 
401-450 


; 
| 


| 
Fd bod be 
Aid 


| 
ty 
ra 
| 


ccCnnn *A* mumam SEQ=yyy ID=ccccc 
PG=XXXXXxXxx DIAGNOSTIC 


The underlined segments of the diagnostic 
message are variable. 


TEXT this field of up to five lines 
contains the current PLAN statement. 
It is printed only if the long-form 
diagnostic is printed. Character posi- 
tions are printed to the left of the 
text. 


ccc is component code indicating wheth- 
er the error was generated by PLAN 
(CCC=DFJ) or by the user (CCC=***). 


nnn is the three-position error number 
provided as N1 in the call to the PLAN 
error subroutines. For PLAN errors 
(DFJ), nnn is in the range of 1-99 for 


PHRAS errors; 101-199 for execution 
errors; 201-299 for PSCAN errors; 701- 
799 for 1130 PLAN errors; 801-899 for 


DOS PLAN errors; 901-999 for OS PLAN 


ERRORS. 


A is an action code. E indicates an 
exit from PLAN; R indicates a PLAN 
level error recovery; C indicates con- 
tinued processing; O indicates a pause 
for operator intervention. 
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mmmm is the error code provided as N2 
in the call to the PLAN error 
subroutines. 


SEQ=yyy is the three-position sequence 
of the PLAN statement currently being 
processed relative to the first state- 
ment processed following the last level 
0 command. 


ID=ccccc provides the five-character 
contents from the identification field 
of the last PLAN input record processed 
before the diagnostic routine call. 


PG=xxxxxxxx is the name of the module 
that issued the call to the PLAN error 
subroutines. 


DIAGNOSTIC is the text of the literal 
indicated by LIT in the diagnostic 
routine call. If LIT is zero (literal 
character count) in the calling 
sequence, no literal message will be 
written, and the field is filled with 
asterisks. The literal message is 
limited to 76 characters. 


(LIST ERROR FILE | 


— —~-4 
| CALL ERLST | 


CALL _ERLST is a subroutine that may be 
called to force a dump of the error message 
queue file (DYNAMIC file 255, drive 0). 
Processing of the current statement is 
terminated and control is passed to SCAN 
to process the next input record. ‘This 
subroutine supports the technique of post- 
listing diagnostics. The PLAN error mes- 
sage queue file is automatically dumped 
when a level 0O or level 1 phrase is 
encountered or when a /* input statement is 
processed. 


pon - - + 1 
[WRITE DIAGNOSTIC TO PLAN ERROR FILE | 


}----------------------------------------- { 
| CALL EWRIT (NCTL, ARRAY) 


| 
| NCTL Associated carriage control | 
| function | 
| ARRAY User array containing the | 
| diagnostic | 


So mee We DE eit SS SEE MOT eh NSE EE OR SH EE eR TON eS RY cD a A aD MY CY ES SENPD AEDT sin SUE ahi etn “ERD ren Pie crs mee ote cer y eee aie 


|ADD PHRASE: TEST, (25)*SAMPLE DIAGNOSTIC'; | 
| TEST; | 
i : | 
| ° [ 
| : | 
| COMMON L(625),LS(15) ,CA(510) | 
| CALL EWRIT (1,CA(25)) | 
L 


CALL _EWRIT(NCTL,ARRAY) is a subroutine that 
allows a user to enter diagnostics into the 
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PLAN error message queue file (file 255, 
drive 0) in a format that may be processed 
by ERLST. Any diagnostic written to the 
file will be automatically purged as 
defined under CALL ERLST. NCTL in the 
calling sequence defines the carriage con- 
trol functions to be associated with this 
diagnostic and has the same meaning as 
defined for CALL PCCTL. Array is a pointer 
to the first word (character count) of the 
PLAN literal that contains the diagnostic 
text. The maximum number of characters in 
the literal is 120. 


5.11.7 SORT/MERGE 


{CALL PSORT(ID) 
{CALL PMERG(ID,JD,KD) 


ID File control block of SORT file or 
MERGE output file 

JD file control block of first 
merge file 

KD file control block of second 
MERGE file 


~------- 


COMMON L(625),1S(15),CA(510) ,, KA(1) 
DIMENSION JD(2),KD(2),1ID(2) 
EQUIVALENCE (KA(1), (A(1)) 

FIND ERASABLE COMMON 

NEC = LS(8) 

IpD(4) = 1 

JD(1) = 27 
KD(1) = 34 

SET UP SORT CONTROL FIELDS 
RECORD SIZE 

KA(NEC) = 25 

SORT/FIELDS/ RECORD 
KA(NEC+1) = 1 

FIRST SORT KEY 

KA (NEC+2) 
KA (NEC +3) 
KA (NEC+4) 
CALL FIND (ID,0,0,1) 
CALL FIND (KD, 0,0,0) 
CALL FIND (JD,0,0,1) 
CALL PSORT (ID) 

CALL PSORT (KD) 

CALL PMERG (JD,ID,KD) 


Q 


2 


oud 
Ee w 
ee ee ee 
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CALL PSORT (ID) is a subroutine that 
initializes and calls in the PLAN DYNAMIC 
FILE SORT facility. ID is a pointer to the 
first word of the open file control block 
of the file to be sorted. The file to be 
sorted is replaced by the _ sorted file. 


ID(2) must reflect the file size to be 
sorted. If the entire file is to be 
sorted, the CALL FIND automatically satis- 


fies this requirement. 
portion of the file is to be sorted or 
merged, ID(2) must be modified to reflect 
the intent. COMMON outside of that defined 
by Switch Word 9 may be destroyed. 


However, if only a 


CALL PMERG(ID,JD,KD) is a subroutine’ that 
invokes the DYNAMIC file MERGE facility. 
ID is a pointer to the first word of the 
open file control block for the file that 
is to receive the merged file. JD and XD 
are pointers to the file control blocks of 
the DYNAMIC files to be merged. JD(2) and 
KD(2) must reflect the file sizes to be 
merged. 


PSORT/PMERG results in the overlay by the 
PLAN loader checkpoint facility (CALL 
LCHEX) of the module issuing the call with 
PSRTA/PMRGA. Use of these functions 
requires uniform-length logical records 
written by the DYNAMIC file routine WRITE. 
Sort/merge keys may be located at random 
within the record. They may be binary, 
alphameric, or numeric (integer or 
floating-point). The sorted file replaces 
the original file on disk. The merge phase 
creates a file from any two existing files. 
Parameters that control sorting and merging 
must be stored by the calling program in 
the first positions of ERASABLE COMMON as 
defined by Switch Word 8. 
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Nk a a ala eas Co ee T 

| | ASCENDING/ | 

| | DESCENDING | 

| | & | 

| TYPE OF SORT | MODE | 
oo. roo. i s 
| ALPHAMERIC | +1 | 
|----------------—--- 4---------------- $----- 
| ASA STANDARD | | 

| INTEGER | + 2 | 
|--~-------------—-~- 4---------------- $----- 
{| 32-BIT [ | 

{| FLOATING-POINT | + 3 | 
|--------------------- {------—--------- 4----- 
| 32-BIT | | 

| LOGICAL BINARY | + 4 | 
|---—------—---——---- fo-- === 4----- 
{ 16-BIT | | 

| INTEGER | £5 i 

Panton Oe We eee ate ne cemne eet eaee 4$-+-------------- 4----- 
| LONG-PRECISION | | 

{ (SYSTEM/360 ONLY) {| + 6 | 

ca cea ed ae aaa i Wesel espe eaten ome eee ae 
Figure 11. Sort control fields 

Figure 11 illustrates the sort control 


fields and their meanings. The types of 
sorts and merges that may be invoked are: 


Alphameric. Any sort field definition 
may define a sort key of from 1 to 256 
consecutive EBCDIC characters to be 
sorted. The field must not extend beyond 
the end of the logical record. 


ASA Standard Integer. Bach sort field 
definition may define a sort key of from 


1 to 512 consecutive ASA fixed-point 
integer numbers to be sorted. The field 
must not extend beyond the end of the 
logical record. 


Floating-Point. Specifications for the 
floating-point sort are identical to 


those defined above for ASA _ standard 


integer. 


Logical Binary. Each sort field defini- 
tion defines a 32-bit word that is to be 
matched against the extraction mask (AND) 
and then sorted in logical sequence. 


Half-Word or One-Word Integer. Each sort 
field definition may define from 1 to 


1024 16-bit consecutive binary integers 
to be sorted. The field must not extend 
beyond the end of the logical record. 
Since the record length is a definition 
of 32-bit words, it is not possible to 
sort the file as a contiguous series of 
16-bit integers. 


Long-Precision (System/360 only). Each 
sort field definition may define from 1 


to 256 64-bit consecutive long-precision, 


94 SUBROUTINE USE (5.11.3) 


15 SEPTEMBER 1969 


SSiep poy, ease Bern Pe fe sae eee 

| 

DISPLACEMENT | | 
=RELATIVE { | 
BYTE | LENGTH | 
--—------------ }---------------------------4 
| # OF CONTIGUOUS | 

O12, ude l ELEMENTS | 
-~------------- $---------------------------} 
l # OF CONTIGUOUS | 

Ofte By Giese i ELEMENTS 
a Rang SiapSeaE aE Sa OE Sena EE 
# OF CONTIGUOUS | 

0,4,8, ee | ELEMENTS | 
a in a cn ec a ae a a a ae 4------- | 

{ 32-BIT | 

O54 Oy) aa | EXTRACTION MASK | 
~~------------- }--------------------------- 
# OF CONTIGUOUS | 

a are | ELEMENTS l 
Se Se 1 Satan aac aaa | 
{ # OF CONTIGUOUS | 

0,8,16, ... | ELEMENTS | 
seen ae ee es SE aD ae ae ee a sD cc in as a ce a ne a ce ae ee mn es i ecm a J 


floating-point binary numbers. The field 
must not extend beyond the end of the 
logical record. 


The ascending/descending mode indicator is 
a binary integer that is positive if the 
sort field is to be sorted into ascending 
sequence and is negative if a descending 
sort is indicated. The absolute value of 
the integer indicates the type of sort as 
shown. 

The displacement is an integer value that 
is a relative byte displacement from the 
beginning of the record to the leftmost 
byte of the sort field. 


The length field defines the number of 


consecutive elements to be sorted except 
for the logical sort. For logical sorts 
the field is a mask that is combined by a 


logical AND with the word to be sorted. 


The first word of erasable COMMON must 
contain the logical record length in 32-bit 
words. It must be a positive integer not 
greater than 512. 


The second word contains the number of 
three-word sort control groups (M) and must 
be a positive integer in the range 99>M<(L/ 
3-2), where L is’ the length of ERASABLE 
COMMON. 


Words 3,6,9... contain the mode indicators 
as shown in Figure 11, column 2. 


Words 4,7,10 contain the displacement of 
the first element in the sort field. 
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Words 5, 8, 11... contain the count of 
consecutive elements or the extraction mask 
as defined in the length column in Figure 
11. 


The following example shows the status of 
erasable COMMON required to effect an 
ascending sort on a file with a record 
length of 20 words. The sort is floating- 
point on word 5 within word 12 (major 
field). 


ERASABLE 
COMMON CONTENT 
1 20 Record length 
2 2 Number of sort keys per 
record 
3 3 First three-word group 
a Gq (major field key 
5 1 indicators) 
6 3 Second three-word group 
7 16 (minor field key 
8 1 indicators) 
Exception conditions are handled as 
follows: 


1. When the CALL PSORT/PMERG is executed, 
and an indicated file is found to be 
closed, PLAN level error recovery 
(phrase abort) is initiated. 


2. A merge file found to be unsorted 
results in a phrase abort. 


3. If the length of the file divided by 
the specified record length is not an 
integral value, the short record is 
undisturbed. 


4. If an error is found in the’ sort/merge 
definition in erasable COMMON, a phrase 
abort is initiated. 


5. On PMERG insufficient space to complete 
the merge will result in a phrase abort 
condition. 


5.11.8 SORT/MERGE KEY DEFINITION 


The diagrams below indicate how disk data 
set displacement varies for different sort/ 
merge keys rather than the logic of core- 
array storage. Array position corresponds 
to in-core subscript of record when read 
from disk. 


Displacement Keys for ASA Integer Data and 
ASA Floating-point Data 


te 
ARRAY POSITION |{I1(1)] = {1 (2) 


KEY { 0 { 4 | 8 r 
, LL 
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Displacement Keys for 16-Bit Integer Data 


1I(1) fI(2) fXC3)] TCH) | T05) | (6) | 
t----4----}----}----4----4---—J 
KEY 1o |2 |4 | 6 | 8 |[ 10] 
a a a ee ee ee | 


ARRAY POS. 


Displacement Keys for EBCDIC (Literal) 
Information 


TT 
[A[L{P[H/A[N[U[MJE[RIT Ic | 


--+--4 


ARRAY POS. 


{O]1]2,31415] 6] 7] 8]9]10,11] 
L-L-LoL-Lib Lid d b td 


KEY 


Displacement Keys for Binary SORT 
ARRAY POSITION 


KEY | of 4 


5.11.9 PLAN SEQUENTIAL I/O ROUTINES 


The following subroutines provide over- 
lapped, buffered I/0 capability from a 
module via subroutine calls. Total compa- 
tibility between all systems supported by 
PLAN is provided. Reread capability is 
also provided within the framework of FOR- 
TRAN, as well as variable input/output 
formatting capability. 

This set of routines is broken into the 
following general classifications: 


1. Buffer Assignment (1130 only) 
2. Input/Output 
3. General Control 


4. Format Control 


r- 
| BUFFER ASSIGNMENT 


b---- se sen ee cov ae a ce ane ee we ene a ee ee ce ur en ce a 


1 
| 
CALL PSBFA(NOD) | 
CALL PSBFB(NOD) | 
CALL PSBFC (NOD) | 
CALL PSBFD(NOD) | 
CALL PSBFE(NOD) | 
CALL PDBFA (NOD) i 
CALL PDBFB(NOD) { 
CALL PDBFC (NOD) | 
CALL PDBFD (NOD) | 
CALL PDBFE(NOD) | 

| 

| 

m | 


NOD PLAN device code definition 


ee ee ce ee ee ee ee ee ee oe a 


The buffer assignment routines provide 
Single or double buffer assignment for each 
device used within a module. Each device 
to be used within the module must be 
specified as an argument of a buffer 
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assignment routine. Two different devices 
should not be associated with a particular 
buffer set, that is, each subroutine should 
be called only once within any module. The 
buffer assignment routines are not required 
(they will execute as a no-op) in System/ 
360 OS and DOS PLAN. 


CALL PSBFA(NOD), CALL PSBFB(NOD), CALL 
PSBFC(NOD), CALL PSBFD(NOD), and PSBFE(NOD) 
are five calls that allow five single- 
buffer sets to be assigned to input/output 
devices (NOD). NOD defines the device to 
be associated with a particular buffer set. 


The allowable values are the same as those 
defined for CALL IOCS. 

CALL PDBFA(NOD), CALL PDBFB(NOD), CALL 
PDBFC(NOD), CALL PDBFD(NOD), and CALL 
PDBFE(NOD) are five calls that allow five 


double-buffer sets to be assigned to input/ 
output devices (NOD). Use of double-buffer 
sets allows automatic overlapped input/ 
output operations. NOD defines the device 
to be associated with a particular buffer 
set. The allowable values are the same as 
those defined for INPUT and LIST under CALL 
rocs. 


ee RL A HO SY A OS SON UNS A SN NR A NN a 5] 


c 

|READ/WRITE SEQUENTIAL FILES 
[CALL PLINP (NOD) | 
{CALL PLOUT (NOD) 


{| NOD PLAN device assignment 


Cc READ AND LIST A FILE 
CALL PSBFA(100) 
CALL PDBFA(0) 
5 CALL PLINP(0) 
CALL PLOUT(100) 


nen ame S208 eek OS cee OE eek OS ee OO 
ee cee ees cee eee eS eet eee ee eee ee eee ee oles ee ee ee eee ly cee 


Cc TEST FOR END OF FILE 

e 

e 

e 
Cc IF NOT END-OF-FILE 

GO TO 5 

Oh a ee 
The input/output routines provide for 


transfer of information from/to device NOD 
to/from a buffer as defined in the call to 
the buffer assignment routine. A pointer 
is set to the buffer to allow communication 


with the format control routines. When 
double buffering is specified, automatic 
overlapped transfer is initiated where 


possible. These routines wait until pre- 
viously initiated I/O on the current buffer 
is complete. 


CALL PLINP(NOD) is a subroutine call to 
transfer a record from the device NOD to 
the buffer set associated with NOD. 
Overlapped, look-ahead reading is initiated 
where possible. NOD may be any device 
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specified for INPUT under CALL IOCS. Posi- 
tions outside the range of the buffer are 
considered to be blank. An invalid NOD 
causes the call to function as a NOP. 


CALL PLOUT(NOD) is a subroutine call]. to 
transfer a record from the buffer set 
associated with device NOD to device NOD. 
Overlapped operation is initiated when 
possible. NOD may be any device’ specified 
for LIST under CALL I0CS. Positions out- 
side the range of the buffer are lost. The 
buffer is automatically cleared before for- 
matting begins. An invalid NOD specifiica- 
tion causes the CALL to function as a NOP. 


poo - - -- - - - - - - - - - + - 
TEST DEVICE STATUS 
}------------------------+-+--- +--+. 
| IF (PIOC(NOD) )1,2,3 

| 

| NOD PLAN device designation 

| 1 Exit for busy 

| 2 Exit for invalid device 

| 3 Normal exit 


CALL PSBFA (101) 
CALL PSBFB(102) 
CALL PDBFA(1) 
CALL PDBFB(2) 
1 DO 25 I=1,2 
Cc IS DEVICE VALID AND NOT BUSY 
2 IF (PIOC(I)) 2,30,5 
Cc CHECK OUTPUT DEVICE 
5 IF (pIoc(I+100)) 5,30,10 
10 CALL PLINP(T) 
Cc TRANSFER INPUT BUFFER TO OUTPUT 
Cc BUFFER (SEE TRANSFER BUFFER 
Cc CONTENTS) 
CALL PBFTR (1I,1+100) 
CALL PLOUT (1I+100) 
Cc TEST END OF FILE 
e 
e 
e 
25 CONTINUE 
GO TO 1 
Cc INVALID DEVICE 
30 PAUSE 30 


eee SS ee A ES ec ES a NS QR SS eS QE EG Sees een SE SE ces eee momen emems eon andes cme cee mee comes coe aoe onbey mee ae 


The busy status of any device may be tested 
with the following function test: 


IF(PIOC(NOD)) 1,2,3 


Statement number 1 is executed if the 
device specified by NOD is busy. Statement 
number 2 is executed if NOD is an invalid 
device specification. Statement number 3 
is executed if the device specified by NOD 
is not busy. 
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a eo ee = 
{QUIESCE 1/0 | 

i a a a as ia So cs ce ms cm ents Sects a ee Sb sens is Ss a cm sin S'S 4 
| CALL PBUSY i 
j----------------------------------------- { 
| ° | 
l . | 
{ ° | 
ic WAIT UNTIL ALL I/O IS COMPLETE | 
| CALL PBUSY | 
I ° | 
{ ° [ 
I ° i 
i cs sc esas es ae te oe ees ee es d 


CALL PBUSY is a subroutine that returns 
control to the calling program only when 
all devices controlled by CALL PLINP and 
CALL PLOUT are found to be not busy. This 
call need not be issued before terminating 
any module in which CALL PLINP or CALL 
PLOUT are issued because the PLAN loader 
performs the function. However, any 
instructions to an operator requiring a 
change in a device status should be pre- 
ceded by a call to PBUSY. 


Qe a ee Ps ee gd BT Re 1 
| TRANSFER BUFFER CONTENTS | 


t- 
[CALL PBFTR(NODF, NODT) { 


I { 
| NODF PLAN device code of "from" buffer| 
| NODT PLAN device code of “to™ buffer | 


| (See "Test Device Status" for example) | 


CALL PBFTR(NODF,NODT) is a subroutine that 
results in the transfer of data from the 
buffer associated with NODF to the buffer 
associated with NODT. The shortest buffer 
controls the transfer termination. 


The following general control routines pro- 
vide miscellaneous control functions asso- 
ciated with a particular device (NOD). 
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|CALL PCCTLCNOD, KTL) 

| 

{ NOD PLAN device assignment 

| KTL Control function code 

}-—-—---- ----------—--_—-----_---------_---- 
| 


| e 

| e 

| e 

jc DOUBLE-SPACE LISTING 

| CALL PCCTL (100,-2) 

|c IS PAGE RESTORE REQUIRED 

| IF (PEOF(100)) 5,5,10 

| 5 CALL PCCTL (100,1) 

jc PRINT 

| 10 CALL PLOUT(100) 
e 

: 

| e 

L 


ae eee cee ee ee ee oe ee oe lee ee eee ees ce eee ele ces ees ee et ones eee ot 


CALL PCCTL(NOD,KTL) is a subroutine call 
that defines a control procedure, to be 
executed in conjunction with the next 
input/output operation on device NOD as a 
result of CALL PLOUT(NOD) or CALL PLINP( 
NOD). Allowable values of KTL are shown in 
the following table. The call will be 
ignored if NOD is a device on which the 
function may not be executed. 





Note carefully that the most recent call to 
PCCTL prevails. For example, a request for 
a double-space following a request for a 
page skip without an intervening call to 
PLOUT will result in a missed page skip. A 
page skip request when the carriage is at 
channel 1 will result in a skip to a new 


page. 


N Function 
1-12 Skip paper to channel N 
0 Suppress space before printing (note 
that suppress space results in no 
carriage return on the 1130 Console 
typewriter or 1050 on the DOS 
System) 
-1 Single-space before printing (note 
that this is automatic) 
-2 Double-space before printing 
-3 Triple-space before printing 
13 Select stacker 1 
14 Select stacker 2 
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ewe ee = g i 
[TEST END-OF-FILE STATUS | 
a a a aa tn re ce { 
{IF (PEOF(NOD)) 1,2,3 | 

| 
} NOD PLAN device code definition | 
| 1 Logical EOF on exit | 
| 2 Physical EOF or invalid device ] 
| code exit | 
| 3 Normal exit | 
a ce cc ee se ee ie ce eS ech sD DS Sr ct eu cue cae em em cu sn { 
[See “Device Control" for example | 
eA ee Np RT ne PE Pt en Pa aE EOI J 


The physical end-of-file indicator is 
turned on by reading or punching the last 
card. The condition may be detected by 
testing the indicator with the function 
test PEOF. The logical end-of-file indica- 
tor is turned on by reading a record with 
UREND in positions 1-5 or by: sensing chan- 
nel 12 on the printer. Channel 12 is 
Simulated on OS and DOS PLAN by a line 
counter. The record containing the logical 
end-of-file may be accessed by the conver- 
sion routines if desired. The logical EOF 
indicator remains on for only one cycle. 


The end-of-file test is a function test as 
shown below. Statement 1 is executed if 
the logical end-of-file indicator is "on"; 
statement 2 is executed if the physical 
end-of-file indicator is “on™ or an invalid 
device is tested; statement number 3 is 
executed if neither end-of-file indicator 
is “on*. 


IF (PEOF(NOD)) 1,2,3 


NOD is the device on which the input/output 
operation was executed that might have set 
the end-of-file indicator. Note that when 
the physical end-of-file indicator is 
turned “on™ the device cannot be accessed 
until PLAN is rescheduled (a new execution 
of PLAN is initiated). 


The procedures below are followed by PLAN 
(PSCAN) when end-of-file conditions or spe- 
cial input records are processed. 


CONDITION ACTION 
LOGICAL EOF Initiate a phrase abort with 
(UREND) the appropriate diagnostic. 


PHYSICAL EOF Return to monitor after com 
pletion of processing of the 
current command. 


/* Return directly to monitor. 
// Return control to monitor. A 
diagnostic is issued and the 


record is not processed by 
monitor. 
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q 


z 


Q 


Q 


Q 


10 


io) 


15 


19 


qa aA A 


25 
30 


Q 


20 


Qo 062 


35 


oe ee ee ee ee ee ee ee ee ee ee ee ee ee ee Se re re ee re ee ee ee CE ED ee ES es ee a ee ee ee ee ee eee oe ee oe ee 
Q 


3 
5 
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PIIN(NOD,I, NW, ARRAY) 
PIOUT (NOD, J, NW, ARRAY) 
PAIN(NOD, I,,NW, ARRAY) 
PAOUT (NOD,J , NW, ARRAY) 
PFIN(NOD, I,NW, ARRAY) 
PFOUT (NOD, J ,NW,, ARRAY) 
PEOUT (NOD,J ,NW, ARRAY) 


PLAN device specification 
Input record position from which 


to extract field 


Output record position into which 
the field is to be stored 
Number of characters in the field 
or field width and decimal 


position indicator 
User array 


a i a a a a ne a ee a ee ce ca ee ce ae ee me a a ct ea 4 


LIST SEQUENCE ERRORS IN CARD DECK 
COMMON L(625), LS(15), M(510), 
1K(8), KK(8),A(2) 


DATAA/ * ERRO* , *ORS‘/ 

OPEN BUFFER 

CALL PDBFA(0) 

CALL PSBFA(100) 

NERR = 0 

CLEAR OLD SEQUENCE 

DO 5 I=1,8 

K(I) = 0 

CALL PLINP(0) 

GET NEW SEQUENCE 

DO 10 I=1,8 

CALL PAIN(0,72+1,1,KK(I)) 
CHECK SEQUENCE 

DO 15 I=1,8 

IF (K(I)-KK(I)) 19,15,35 
CONTINUE 

EQUAL ERROR 

GO TO 35 

TEST END-OF-FILE 

IF (PEOF(0)) 20,20,25 
SAVE OLD SEQUENCE 

DO 30 I=1,8 

K(I) = KK(T) 

GO TO 6 

GENERATE COUNT OF ERRORS 
CALL PIOUT(100,1,5,NERR) 

CALL PAOUT(100,6,7,A) 

CALL PLOUT(100) 

EXIT MODULE 

CALL LRET 

ERROR IN SEQUENCE 

CALL PBFTR(0,100) 

CALL PLOUT(100) 

NERR = NERRt1 

GO TO 19 

END 


The format control routines 


transfer and format 
from/to the system buffer 


| 





ees AE es SR Se a a 





be eee ee a OE A een SN ee a 


for 
conversion of data 
associated with 


the device to/from user-specified memory. 


The names of routines 


that transfer data 


15 SEPTEMBER 1969 


from the system buffer are suffixed with 
the characters "IN". The names of routines 
that transfer data to the system buffer are 
suffixed with the characters “OUT". The 
second character of the subroutine name 
specifies the format conversion type. 


ROUTINE CONVERSION 

PIIN Integer input conversion 

PFIN Floating-point input conversion 

PAIN Hollerith (A-format) named input 
conversion 

PIOUT Integer output conversion of 
fixed-point numbers 

PFOUT Decimal output conversion of 
floating-point numbers with 
rounding 

PEOUT Exponential output conversion of 
floating-point numbers with 
rounding 

PAOUT Output conversion of named Hol- 
lerith data 

The input conversion routines have the 


following arguments in the call list: 
CALL PXIN (NOD,1I, NW, ARRAY) 

Argument Function 

NOD The input device (see 5.11.5) on 


which the data to be converted was 
read as the last record. 


I The relative position within the 
record of the first ‘character of 
the field to be converted. 


NW The number of positions within the 
record to be converted, starting 
at I. In PFIN, the tens. and 
hundreds positions define the 
field width. The units position 
defines the number of decimal 
positions in the data field. An 
included decimal point or explicit 
exponent overrides the units posi- 
tion specification. 

ARRAY The 32-bit word that is to receive 

the converted data value. 


The output conversion routines have the 
following arguments in the call list: 


CALL PXOUT (NOD,J,NW, ARRAY) 
Argument Function 


NOD The output device (see CALL I0CS 
under "Utility Subroutines", 5.11. 
5) on which the converted data 
record is to be written on the 


next output record. 


J The relative position within the 
output buffer at which the first 
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position of the converted data is 
to be stored. 


NW The number of positions to be 
occupied by the converted data 
field, starting at J. Data con- 


verted by PIOUT, PFOUT, and PEOUT 
is right-justified. Leading zeros 
are suppressed. In PFOUT, and 
PEOUT the tens and hundreds posi- 
tions define the field width. The 
units position defines the number 
of decimal positions. If pos- 
sible, the exponential format is 
used when the field width is too 
small to allow the decimal format. 
ARRAY The location in memory from which 
the data to be converted is to be 
taken. 


The following rules for these routines 
indicate action taken by the PLAN I/0 
conversion routines under various data 
conditions: 


Routine Conversion Rules 
PIIN 1. Leading blanks to and following 
the sign are ignored. 
2. Signs may be +, -, or &. 
3. Digits are collected after the 


first numeric until the speci- 
fied field is processed ora 
nonnumeric character is 
processed. 


4. A fixed-point zero is the result 
of processing no numerics. 

5. All numbers are treated modulo 
(the maximum positive or maximum 
negative fixed-point number). 

6. Example: 
b-b156 = -156 
1-56 = 1 
bbb.b = 0 


PFIN 1. Leading blanks to the left of 
the sign or within an exponent 
field are ignored. 

2. Other blanks are 
zero. 

3. Input collection is stopped when 
a second decimal is processed. 

4, Exponents may be represented and 
preceded by E, by leading 


treated as 


blanks, and a sign, or bya 
Sign. 

5. The collection is stopped by a 
nonblank, nonnumeric following 
the exponent. 

6. Numbers too small to be repre- 


sented are set to zero. 
7. Numbers too large to be repre- 
sented are set to FALSE. 
8. Example: 
bb+5b.b6 = 50.06 
Tbbb+b5 = 700000000 
-.7E3 = -700 
1.E1bb=10 
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PAIN 1. Characters are collected and 
placed in successive array words 
in A& format. 

2. The unused portion of the 
word is not disturbed. 


last 


PIOUT 1. Leading zeros are suppressed. 
2. The sign, if minus, is placed 
adjacent to the leftmost digit. 
3. Truncation is from the left with 
the sign being truncated first. 


PFOUT 1. Leading zeros to the left of the 
decimal point are suppressed. 

2. No position is required for the 
sign unless it is negative. Any 
minus sign is placed to the left 
of the most significant digit or 
the decimal point if there are 
no digits left of the decimal 
point. 

3. Truncation from the 
automatic. 

4. Truncation from the left results 
in a call to PEOUT. 

5. If (W-D-S-M-1) is less than 
zero, the call is treated as a 
call to PEOUT. 

W = number of output positions 

D = number of digits to right of 
decimal 
number of significant digits 
left of decimal point 
1 if the number is negative 
and 0 if the number is 
positive 


right is 


“a 
5 


M 


PEOUT 1. No sign position is required 

unless the sign is negative. 

2. Positive exponents are in the 
form: 

Etnn 

3. If (W-D-M-S) is equal to or less 
than 0O when D=0, then D is set 
equal to W-M-6. If this D is 
negative, the output field is 
set to asterisks. 


PAOUT 1. Characters are transferred from 
successive array words that are 
assumed to be in A4& format. 


The following example illustrates the 
sample program to read and list cards and 
accumulate the total of the data punched in 
columns 21-27 of the data cards. The data 
deck is terminated with a card punched 
UREND (logical EOF) in cc. 1-5. 
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CALL PDBFA(1) 
CALL PDBFB(101) 
SUM = 0. 
CALL PCCTL (101,1) 
5 CALL PLINP(1) 
IF (PEOF(1)) 20,20,15 
15 CALL PFIN(1,21,70,A) 
SUM = SUM+tA 
CALL PBFTR(1,101) 
CALL PLOUT (101) 
IF (PEOF(101))5,5,10 
10 CALL PCCTL(101,1) 
GO TO 5 
20 CONTINUE 


END 


Note that a buffer may be used for both 
output conversion routines and input con- 
version routines. This allows a user to 
utilize the facilities of the conversion 
routines for converting internal data. 


The following example illustrates a program 
that reads a deck of cards, and adds a 
three-character identification field and 
five-position sequence field before repro- 
ducing the deck on the system card punch 
and listing it on the system printer. The 
starting sequence number, increment, and 
identification field are read at the start 
of each deck. 


COMMON L(625),LS(15),M(510) 
ASSIGN BUFFER FOR CONTROL INFORMATION 
INPUT 
CALL PSBFA (3) 
ASSIGN PUNCH FILE BUFFER 
CALL PDBFB(104) 
ASSIGN PRINT FILE BUFFER 
CALL PSBFB(102) 
ASSIGN READ FILE BUFFER 
CALL PDBFA(2) 
READ CONTROL INFORMATION 
CALL PLINP (3) 
CONVERT ID FIELD FROM POSITIONS 1-3 
CALL PAIN(3,1,3,A) 
CONVERT STARTING SEQUENCE NUMBER 
POSITIONS 5-9 
CALL PIIN(3,5,5,1) 
CONVERT SEQUENCE INCREMENT FROM 
POSITIONS 10-14 
CALL PIIN(3,10,5,INC) 
EJECT TO NEW PAGE 
CALL PCCTL(102,1) 
READ CARD 
CALL PLINP(2) 
MOVE RECORD TO PUNCH — PRINT BUIFER 
CALL PBFTR(2,104) 
CALL PBFTR(2,102) 
c MOVE IDENT TO OUTPUT 
CALL PAOUT(102,73,3,A) 
CALL PAOUT(104,73,3,A) 
c MOVE SEQUENCE TO OUTPUT 
CALL PIOUT(102,76,5,1) 
CALL PIOUT(104,76,5y1) 
c FILL LEADING ZEROS 


= 
oO 


» 
wn 
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NO 
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DO 23 K=76,79 
CALL PAIN(102,K,1, KK) 
CALL PUNPK (KK, KK,1) 
IF (KK-64) 21,21, 24 
21 CALL PAOUT(102,K,1,240) 
23 CALL PAOUT(104,K,1,240) 
WAS EOF PROCESSED ON READ 
24 IF (PEOF(2))10,30,25 
PUNCH CARD 
25 CALL PLOUT (104) 
PRINT 
CALL PLOUT (102) 
INCREMENT SEQUENCE 
I=I+INc 
IS THIS LAST LINE ON PAGE 
IF (PEOF(102))15,15, 20 
RETURN TO PLAN ON PHYSICAL EOF 
30 CALL LRET 
GO TO 30 
END 


oO 2a 49 08429 a4 90 


If NOD equals zero for any function asso- 
ciated with input, the current PLAN input 
device is used. Use of 100 for any func- 
tion associated with output results in use 
of the current PLAN output device (see 
5.11.5). 


The following example illustrates the trun- 
cation procedures of PIOUT. A FORTRAN 
program is shown followed by the output 
attained: 
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DATAV1/"A="/,V2/"B="/,V3/*C="/,V4/"D="/, 
V5/° E="/, V6/"F="/ 
DATAV7/" G="/ ,V8/*H="/,V9/"I="/,VA/*3="/ 
CALL PSBFA(12) 
CALL PAOUT(102,01,2,V1) 
CALL PIOUT(102,03,8,-32767) 
CALL PAOUT(102,11,2,V2) 
CALL PIOUT(102,13,7, 32767) 
CALL PAOUT(102, 20,2,V3) 
CALL PIOUT(102,22,6,-32767) 
CALL PAOUT(102,28,2,V4) 
CALL PIOUT(102,30,5, 32767) 
CALL PAOUT(102,35, 2,V5) 
CALL PIOUT(102,37,5,-32767) 
CALL PLOUT(102) 
CALL PAOUT(102,42,2,V6) 
CALL PIOUT(102,44,4, 32767) 
CALL PAOUT(102,48,2,V7) 
CALL PIOUT(102,50,3, 32767) 
CALL PAOUT(102,53, 2,V8) 
CALL PIOUT(102,55,2, 32767 ) 
CALL PAOUT(102,57, 2,V9) 
CALL PIOUT(102,59,1, 32767) 
CALL PAOUT(102,60,,2,VA) 
CALL PIOUT(102,62, 59, 0) 
CALL PLOUT(102) 

1 CALL LRET 
GO TO 1 
END 


A= -32767B= 32767C=-32767D=32767E=32767 
F=276 71G=767H=671=73= i 


SUBROUTINE USE (5.11.3) 101 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


5.11.10 ARRAY MANIPULATION 


a 
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{CALL PARGO(LS, ARRAY) 
{CALL PARGI(LS, ARRAY) 
[CALL GTVAL (ARRAY, KOUNT, DATA, NSUB) 
{CALL STVAL(ARRAY,KOUNT, DATA, NSUB) 


LS Switch word containing pointer 
ARRAY User data array 
KOUNT Words to transfer 

(TO array for GTVAL) 

(The FROM array for STVAL) 
DATA User data array 

(The FROM array for GTVAL) 

(The TO array for STVAL) 
NSUB Data array initial subscript 


Cc MOVE ARRAY C-A-D-B-A : 
COMMON L(625),LS(15) ,NA(10),NB(10), 
Nc (10) , ND (10) 
DO 5 I=1,10 
NA (1) =0 
NB(I)=10 
Nc (I) =20 
5 ND(1I)=30 
LS (4) =21 
Nc (1) =9 
CALL PARGO(4, NA) 
TRANSFER A TO D 
CALL GTVAL(ND,10, NA, 1). 
LS (4)=11 
CALL PARGI(4,ND) 
TRANSFER B TO A 
CALL STVAL(NB, 10, NA, 1) 
ARRAYS SHOULD BE EQUAL 
DO 25 I=1,31,10 
TF (NA(I)-9)10,15,10 
10 CALL ERROR (111,NA(T),0) 
15 KK=I+1 
KKK=KK+t8 
DO 25 K=KK, KKK 
IF(NA(K)-20) 20,25,20 
20 CALL ERRET(112, NA(K) ,0) 
25 CONTINUE 
CALL LRET 
GO TO 25 


Q 


qo 9 
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Subroutines PARGO and PARGI provide a 
mechanism for easy manipulation of data 
through system Switch Words 4-7. 


Arrays to be transmitted by PARGO and PARGI 
must be in the following PLAN array format. 


eee ON, ee eRe ea ey Pe ee Saar aes a] 
| FIXED- | | | i I 
| POINT | | | | | 
[COUNT | [ I I 1 
| OF | | { { | 
[DATA [1ST | 2ND | [LAST | 
| VALUES | ELEMENT | ELEMENT | nae [ELEMENT | 
tL Le LN ee hh 
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If the resulting "TO" array address is 
lower in COMMON than the _ communication 
array, the call is ignored. No diagnostic 
is issued. 


CALL PARGO(LS,ARRAY) moves a data array 
from ARRAY to the PLAN communication array 
pointed to by PLAN Switch Word LS. Array 
(1) is assumed to contain the number of 
words "M" that are to be transferred from 
Array (2) to Array (Mt1). The count is 
transferred to the position indicated in 
Switch Word LS. The data list is trans- 
ferred to the following positions. 


CALL PARGI(LS,ARRAY) moves a data list from 
the PLAN communication array (pointed to by 
PLAN Switch Word LS) to ARRAY. The first 
position of ARRAY receives the integer 
count Of the number of data values. The 
remainder of the array contains the data 
list. 


The following example shows use of the 
PARGO routine in transferring array F, ina 
module, to communication array location 20. 
Example: 


COMMON L(625), M(255) 
LS (4)=20 


CALL PARGO(4,F) 


LS(15), 


In the above example, if F(1) contained a 
10, then communication array position 20 
would be set to 10 and F(2) through F(11) 
would be transferred to communication array 
positions 21 through 30. 


The following routines allow easy, effi- 
cient transmission of arrays or parts of 
arrays to and from any location in storage. 
Note carefully that arrays to be processed 
must start on 32-bit boundaries. 


CALL STVAL(A,N,B,I)) moves N 32-bit words 


from A(1) through A(N) to B(I) through 
CALL GTVAL(A,N,B,I) moves N 32-bit words 


B(I) through BC(I+tN-1) to A(1) through A(N). 
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5.11.11 BIT, BYTE AND CHARACTER PROCESSING 


ke 
[IF (PCOMP(A,B,N)) 1, 2,3 


A User's first data array 

B User*s second data array 
N Number of words to compare 
1 A less than B exit 

2 A equals B exit 

3 A greater than B exit 


| 
| | 
{ | 
| | 
| | 
| l 
| | 
{ | 
ee ee 
{c 1130 FLOATING-POINT USED. IN EXAMPLE | 
| 
| DIMENSION A(5),B(5) | 
| COMMON L(625),LS(15) ,M(255) | 
| DATA A/‘ABCD'/, B/‘BCDE'/ 1 
{ DO 10 J=1,5 | 
{ A(J)=T | 
| 10 BWI) =Ja | 
IF (PCOMP(A,B,5)) 90,20,90 1 
} 20 A(3)=2. { 
Ic COMPARE HEX 40000082 WITH 60000083 | 
| IF (PCOMP(A,B,5)) 30,80,80 { 
| 30 A(3)=40. | 
Ic COMPARE HEX 50000086 WITH 60000083 | 
| IF (PCOMP(A,B,5)) 40,80,80 | 
| 40 IF(PCOMP(B,A,5)) 70,70,50 | 
| 50 CALL LRET | 
Ic BRANCH HIGH ERROR | 
| 70 PAUSE 70 i 
I GO TO 50 | 
jc BRANCH LOW ERROR | 
| 80 PAUSE 80 | 
\ GO TO 50 i 
jc BRANCH EQUAL ERROR i 
| 90 PAUSE 90 | 
1 GO TO 50 { 
{ END | 
a i i ch sa a cc cg we Ga aes ma cw enc a ce ee eh is i ee ce J 


Two 32-bit arrays may be logically compared 
through use of the PCOMP function. The 
following example illustrates the FORTRAN 
statement necessary to compare five words 
(32-bit logical) of array A to five words 
of array B: 


IF (PCOMP(A,B,5)) 1,2,3 


Statement number 1 is executed if the first 
word of array A that is not equal to the 
corresponding word of array B is less than 
the word in array B. Statement number 2 is 
executed if the entire array A is equal to 
array B. Statement number 3 is executed if 
the first unequal word of array A is 
greater than the corresponding word of 
array B. Care should be taken when compar- 
ing numeric arrays to note the logical 
order of bits. 
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| HEXADECIMAL TO EBCDIC | 


}------------------------------------—---- { 
CALL PHTOE(A,B,N) 


A Hexadecimal array 
B EBCDIC converted array 
N Number of words in array A 


Cc LIST SWITCH WORDS 
COMMON L(625) ,LS(15) ,M(510) 
DIMENSION W(30) 
CALL PSBFA(100) 
CALL PHTOE(LS,W,15) 
DO 10 I=1,15 
CALL PAOUT(100,10*I-9-1/11#*100,8, 
1W(2*I-1)) 
IF (I-10) 10,5,10 
5 CALL PLOUT(100) 
10 CONTINUE 
CALL PLOUT(100) 


fees een ee SE ONS ES SED ES Se ON a eee ee eS gees cee aes eee Oe ee eS 


<2 ee ee ee ee ee ce ee ee ee ee ee ee ee ee ee 
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CALL PHTOE(A,B,N) is a subroutine call that 
converts a hexadecimal array A to an EBCDIC 
array B in A4 format. N words from array A 
are converted to 2*N words in array B. 
PHTOE allows any data to be dumped as a 
hexadecimal listing. The following example 
shows array A and array B_ (hexadecimal 
representation) following the call to 
PHTOE: 


Array A: 60000082C1C2C3C4 
Array B: F6FOFOFOFOFOF8F2C3F1C3F2C3F3C3F4 
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{CALL PBTST (NOP ,NWORD, NBIT, NSKIP) 


NOP Operation to perform 

NWORD Word upon which test is to be 
made 

NBIT Bit to test or test mask 

NSKIP Test result indicator 


2 EA TY A A SS ND LN LS SO NY SES AS LD SS SS A NG SS SE <n 


Q 


CLEAR WORD 
CALL PBTST(0,A,0,NSKIP) 
TURN EVERY OTHER BIT ON 
DO 5 I=1,31,2 
5 CALL PBTST(1,A,1,NSKIP) | 

SET MASK TO EXTRACT ALL BUT BITS 
7-15 FROM WORD 
CALL PBTST(-1,B,0, NSKIP) 
DO 10 I=7,15 

10 CALL PBTST(3,B,I,NSKIP) 
EXTRACT 
CALL PBTST(12,A,B,NSKIP) 
BITS 1,3,5,17,919, 215 234925927929, 
AND 31 SHOULD BE ON 
LIST BITS ON AND TURN THEM OFF 
CALL PSBFA(100) 
DO 15 I=1,32 
CALL PBTST(7,B, I-1,NSKIP) 
IF (NSKIP)12,15,12 

12 CALL PIOUT(100,1,5,I-1) 
CALL PLOUT (100) 

15 CONTINUE 


o) 


an 


QAaQQ = 4 
Ne Ee ee 
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CALL PBTST(NOP, NWORD,NBIT,NSKIP) is a sub- 
routine call to provide manipulative and 
testing functions for any of the 32-bits of 


the 32-bit word NWORD. The bit specified 
by NBIT is in the range of 0-31. NOP 
specifies the setting, resetting, or test- 
ing operation to be executed. If a test 


operation is defined and all bits in the 
test mask match or the specified bit is on, 
NSKIP is set to one; if no bits in the test 
mask match or the specified bit is off, 
NSKIP is set to zero; if only part of the 
bits match, NSKIP is set to minus one. If 
NOP specifies a test under mask operation, 
NBIT is the test mask rather than a bit 
position. If NOP specifies an extract 
under mask, NBIT is the PLAN word that is 
to receive the extracted field and that 
contains the extraction mask. The follow- 
.ing table lists the valid operation codes: 


OP CODES FUNCTION 

<1 Turn all bits “on" 

0 Set all bits "off" 

Set the specified bit “on™ (1) 
Invert the specified bit; if 1 set 
to 0, if 0 set to 1 
Set the specified bit "off" 
Test the specified bit 


(0) 


FW NR 
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5 Test the specified bit and set it 
"on" 

6 “Test the specified bit and invert 

7 Test the specified bit and set it 
"off" 

8 Test the bits corresponding to the 


specified mask 


9 Test the bits corresponding to the 
test mask and set them “on" 
10 Test bits corresponding to the 
test mask and invert them 


11 Test the bits corresponding to the 
test mask and set them “off" 

12 Test and extract the bits corre- 
sponding to the bits in the test 
mask 


The following table illustrates the func- 
tions of various calls to PBTST and shows 
values before and after execution: 


NWORD NWORD 
NOP BEFORE NBIT NSKIP AFTER 
-1 7TEFFFFFFF - ~- FFFFFFFF 
0 7FFFFFFF - - 00000000 
1 T7TFFFFFFF 0 - FFFFFFFF 
2 7FFFFFFF 1 - 3FFFFFEF 
2 7TFFFFFFF 0 - FFFFFFFF 
3 7FFFFFFF 1 = 3FFFFFIFF 
3 7FFFFFFF 0 - TFFFFFIF 
4 7FFEFFFF 1 1 7FFFFFIFF 
4 7FFFFFFF 0 0 7FFFFFFF 
5 7FFFFFFF 1 1 TJFFFFFIFF 
5 7TFFFFFFF 0 0 FFFFFFFF 
6 7FFFFFFF 1 1 3FFFFFIFF 
6 7FFFFFFF 0 0 FFFFFFFF 
7 7JFFFFFFF 1 1 3FFFFFFF 
7 7FFFFFFF 0 0 TFFFFFIFF 
8 7FFFFFFF F0000000 0 TFFFFFFF 
8 7FFFFFFF 70000000 1 TFFFFFPF 
9 TFFFFFFF F0O000000 0 FFFFFFFF 
9 JFFFFFFF 70000000 1 TFFFFFFF 
10 7FFFFFFF F0000000 0 SFFFFFFF 
10 JFFFFFFF 70000000 1 OFFFFFFF 
11 JFFFFFFF F0000000 -1 OFFFFFFF 
11 4FFFFFFF 70000000 1 OFFFFFFF 
12 7FFFFFFF F0000000 1 7FFFFFFF 
NBIT after 70000000 
12 7FFFFFFF 70000000 1 TFFFFFFF 


NBIT after 70000000 
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{CALL PPACK(I,A,N) 
{CALL PUNPK(I,A,N) 
|CALL BREAK(A,J) 


| 

{| A Word containing four bytes 
{} I Integer word with one 

{ right-justified byte 

| wN Byte position indicator 

| 3g Four-word integer array 


Cc REVERSE ORDER OF FOUR BYTES 
DATA A/‘ABCD‘/ 
DIMENSION N(4) 
CALL BREAK (A,N) 
DO 5 I=1,4 
5 CALL PPACK(N(T) ,A,5~1) 


Cc GET 2ND BYTE AND TEST FOR ‘C* 
CALL PUNPK(N,A, 2) 
IF (N(1)-195) 10,15,10 

Cc ERROR 


10 PAUSE 10 
15 CONTINUE 


bee cee A eee AR EN OD ED EE eS a oe OD ie eee aes ce ES ES ee SE ee ae SE 


po eee ce ee eee ee eee eee ae Oe ee ee ee ee ee 


CALL PPACK(I,A,N) is a subroutine that 
masks the rightmost eight bits of the 
integer I into the byte position of array A 
specified by N. Other bytes within A are 
unchanged. 


The following example illustrates a call to 
PPACK to place the letter B (decimal equiv- 
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alent is 194) into bits 0-7 of the word at 
A. Example: 


CALL PPACK(194,A,1) 


CALL PUNPK(I,A,N) is a subroutine that 
inserts the byte specified by N in array A 
into the rightmost byte of the integer word 
I. Bits to the left of the inserted byte 
in I are cleared. 


CALL BREAK (A,J) is a subroutine that 
spreads the four bytes of word A into the 
low-order byte of the four-word integer 
array J. High-order bits in array J are 
set to zero. This subroutine call is 
useful in separating alphameric data in A4 
format into a form that allows ready test- 
ing within FORTRAN. The following FORTRAN 
statements test a literal string and indi- 
cate the position of the first comma 
encountered. The string is assumed to be 
stored in array A. The location of the 
comma will be stored in J1. 


DIMENSION I(4),A(... 
J=1. 
5 J1=J5/4+1 
CALL BREAK(A(J1),I1) 
15 J1=J- (3-1) /74%4 
IF(I(J1)-107) 20,25,20 
20 J=J+t+1 
IF(J1-4) 15,5,15 
25 CONTINUE 
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6.0.0 PROGRAMMING CONVENTIONS 


This section provides a guide to, and the 
regulations for, writing PLAN logic 
modules. A PLAN logic module is a piece of 
program code that has been singly compiled 
or assembled and _ stored/link-edited into 
the program library. The application 
(problem-solver) programmer follows the 
regulations for writing and storing a norm- 
al mainline program but observes the stan- 
dards of PLAN as discussed below. 


There are specific functions that should 
not be used since they are detrimental (or 
fatal) to the successful PLAN execution. 
These functions vary between different sys- 
tems and are specifically detailed in the 
appropriate appendix of this manual. In 
general, any function that gives control to 
the monitor or operating system must not be 
used when PLAN has control. Where func- 
tions are specifically restricted because 
of adverse performance, an equal or more 
powerful function is provided by a PLAN 
subroutine or function. Linkage conven- 
tions compatible with those of FORTRAN are 
used in all versions of PLAN. 


6.1.0 COMMON LAYOUT 


The common statement in any program must 
protect PLAN by providing the proper COMMON 
layout. The items listed below are the 
items (some optional) included in COMMON. 
Sizes are stated in 32-bit words. 


Item: Loader 

Size: 625 (Required) 

Function: This portion of the loader area 
(in COMMON) contains the PLAN 
loader and must remain in memory 
throughout an entire PLAN execu- 
tion (until PLAN returns control 
to the monitor or operating 
system), 

Item: System Switch Words 

Size: 15 (Required) 

Function: A conmunication control area 
required for controlling PLAN but 
accessible to the user for modi- 
fication by program or command. 

Item: Managed Array 

Size: Variable (Optional) 

Function: This array (in COMMON) is that 


portion of the communication 
array that is to be managed 
according to the PLAN level con- 
cept. Communication between the 
application program and problemn- 
describing commands is through 
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Item: 
Size: 
Function: 


Item: 
Size: 
Function: 
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the communication array (managed 
and nonmanaged). The size of the 
managed array is described to the 
PLAN system at language defini- 
tion time (see “Switch Words"); 
however, if undefined, it is 
assumed to have a length of 0 
words. 


Nonmanaged Array 
Variable (Optional) 
This array (in COMMON) 
previously described 
array constitute the communica- 
tion array, that is, the area 
used for communication of data 
input via PLAN commands to the 
application logic modules and 
between various logic modules. 
This portion of the communication 
array, however, is not managed 
according to PLAN level designa- 
tions. This array may also be 
described as that portion of COM 
MON -- not included in the loader 
area, system switch words, or 
managed array -- that will not be 
overlaid by any PLAN system 
module, such as the statement. 
scan module (PSCAN). The size of 
this array may be variable and 
depends on (1) the size of the 
Managed array, and (2) the system 
configuration on which this. run 
is executed. On 1130 PLAN the 
minimum size of COMMON protected 
from overlay by PLAN modules is 
510 words. Execution of ADD 
PHRASE commands may overlay some 
of the communication array. (See 
the appropriate appendix for spe- 
cific communication array size 
specifications.) 


plus the 
managed 


User COMMON (1130 PLAN only) 
Variable (Optional) 

This portion of COMMON may con- 
tain any desired user arrays 
required for transfer of data 


between logic modules. Certain 
PLAN system functions (logic 
modules) may, however, overlay 
this portion of COMMON. These 


functions are: 


Module Used When 

PSCAN A new PLAN statement 
must be processed. 

PERRS A system error diag- 
nostic must be 


generated by the PLAN 
diagnostic processor. 
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PSRTA The PLAN file sort required. 
facilities are PHRAS A new command is to be 
required. entered into the lan- 
PMRGA The PLAN file merge guage dictionary. 
facilities are 
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7.0.0 PLAN SYSTEM CASE STUDY 


This section shows the programming, lan- 
guage definition, and language use involved 
in an application system designed to gener- 
ate solutions to a problem. All the facil- 
ities of PLAN are not illustrated. The 
section serves to illustrate proper forma- 
tion of PLAN modules and PLAN commands. 


7.1.0 PROBLEM DEFINITION 


The problem to be solved in this case study 
development will be defined in increasing 
degrees of complexity. An initial problem 
definition is solved through all involved 
steps, including the FORTRAN programs 
required. Additional requirements are then 
added to the problem definition, and the 
steps to attain the new solution are added. 


The following geometric equivalences may be 
derived from the elements defined in Figure 
12. 


TAN © = BEVEL 

SLOPE? = BASE? + RISE? 
SIN e = RISE/SLOPE 
COS e = BASE/SLOPE 


Figure 12 illustrates the terminology used 
in various aspects of this case study. 


RISE 





BASE 


Figure 12. Terminology for sample problem 
The problem to be solved in this case study 
is defined below. Two solutions to the 
problem are provided. The problem to be 
solved is: 


1. Solve a right triangle when any two of 
the five values (BASE, RISE, SLOPE, 
BEVEL, ANGLE) are given. Note that 
BEVEL and ANGLE may not be the given 
two values since they are mutually 
exclusive. Assume that values will be 
given in decimal. Results should be 
rounded. Suggested logic modules might 
be (1) CALCULATION, (2) PRINT, and (3) 
CSERR. 
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Provide a facility for validating data 
to ensure that two-out-of-five values 
are given. The errors that could occur 
are underspecification and overspecifi- 
cation. Note also that specification 
of ANGLE and BEVEL is a special case of 
underspecification. This testing may 
be accomplished with either logical 
testing within a phrase or a_ separate 
logical testing module. 


7.2.0 LANGUAGE DEFINITION 


The following list is an itemization of the 
functions to be performed through probiem- 
Oriented language statements. These are as 
follows: 


1. The system (communication 
be initialized, that is, a 
command must be defined. 


array) must 
level 1 


2. Data items must be named to allow input 
Of any desired value. 


3. Literal information must be defined for 
heading printouts. 


The following section provides the elements 
of the phrase definition and a brief 
description of the function achieved: 


ELEMENT: 
FUNCTION: 


ADD PHRASE: TRIANGLE SOLUTION, 
The command TRIANGLE SOLUTION is 
defined, and will be recognized 
as the dictionary entry pointer 
to the following context 
definition. 


ELEMENT: 
FUNCTION: 


LEVEL 1, 

The phrase TRIANGLE SOLUTION 
does not depend on any other 
phrase or data. The entire 
Managed communication array is 
to be initialized to logical 
FALSE when the phrase is 
encountered. 

ELEMENTS: (70)BASE, (73)RISE, 
(79) ANGLE, (82)BEVEL, 
The possible input values (BASE, 
RISE, SLOPE, ANGLE, BEVEL) are 
hamed and assigned positions 
within the communication array. 


(76) SLOPE, 


FUNCTION: 


ELEMENT: 
FUNCTION: 


(20) TEST+#T*,,"*T P*CSERR ', 

Position 20 of the communication 
array is assigned the name TEST. 
A logical TRUE is defined as an 
initialization value. A test is 
defined to check for the pres- 
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ELEMENT: 
FUNCTION: 


ELEMENTS 
FUNCTION: 


ELEMENTS : 
FUNCTION: 


ELEMENTS : 


ence of logical TRUE. If the 
location is not found to contain 
logical TRUE, the phrase named 
CSERR is entered into the PLAN 
input stream and is executed. 
Note that check-entries are not 
evaluated until all expressions 
have been evaluated (see “PSCAN 
Execution Sequence", 4.3.25). 


PROGRAMS ‘CALC’, 

Program CALC is to be placed in 
the pop-up list whenever’ the 
command TRI SOL is encountered. 


I(21)N0,J1,1(9) KO, 

Three counters are defined and 
initialized for use in the for- 
mula evaluations defined below. 


I(-8)M, (M)A‘DUM ‘, 
A literal is set that is used to 
cause execution of the DUMP com- 
mand whenever a program error is 
detected (see “Standard PLAN 
Commands", 4.5.0). 


$4:4BASE(J) ?$6, N=Nt1, $6 J=J+3, 
: (J=16)2$7!1S4, $7: (N=2) 2$9, 
$8TEST=-, :$20, $9: (BAS<O)?$11, 
: (RIS<0) 212, =: (SLO<0)?$13, :( 
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: (BEV<0) ?$15, 3 ( 
ANG>90)?$16, :(ANG) & (BEV) ?$ 
17!$20, :$20, $11K=1, :$8,$12 
K=2, :$8, $13K=3, :$8, $14 kK=4, 
$8, $15 K=5, :$8, $16K=6, :$8, 
$17K=7, :$8, $20; 

The formula area is utilized to 


ANG<0) 2?$14, 


test the possible data values 
for FALSE. If the value is not 
FALSE, a count (N) is made. 


After all five possible data 
values have been tested, a test 
is made to determine if two 
non-FALSE data values exist. If 
the number of non-FALSE values 
is not two, TEST is set to 
FALSE. A test is also made to 
assure that the two given values 
are not ANGLE and BEVEL. Note 
that a value of FALSE in TEST 
causes the check-entry defined 
above to fail and thereby place 
CSERR in the pop-up list. A 
negative value for RISE, BASE, 
ANGLE, BEVEL, or SLOPE or an 
angle greater than 90 results in 
TEST being set to FALSE. 


Figure 13 illustrates the logic 
of the expressions defined in 
the preceding element. 
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BAS (J) 


FALSE a N=N+1 


$8 
TEST=FALSE $20 


<a> 

YES 
NO 

ES 


$9 
BAS<0 NO NO 


YES YES 


$11 $12 $13 $14 
K=1 K=2 K=3 =4 


OR BEV $20 
NO ALSE YES 


YES NO 


$15 $16 $17 
K=5 K=6 K=7 


Figure 13. Expression logic 
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The segments of the phrase defined above 
are combined here in their entirety but 
condensed to a minimal representation. 


Spaces in the following example must be 
eliminated to prevent exceeding the 450- 
character statement length limit. 


ADD PHR: TRI SOL, LEV1, (70)BAS, (73) RIS, 
(76)SLO, (79)ANG, (82)BEV, (20) TEST+*T',,‘', 
*TP*CSERR*, PRO'CALC',I(21)N0O, J1, 1(9)KO, 
I(-8)M, (M)A'DUM COM ', $4:4BAS(J) 2?$6, 
N=N+1, $6J=J+3,: (J=16)?S7!S4, $7: (N=2) 25 
9, $8TES=-,:$20, $9: (BAS<0) 2$11, : (RIS<0) ?$ 
12, :(SLO<0) ?$13, : (ANG<O) ?514, : (BEV<0) ?$ 
15, :(ANG>90) 2516, :(ANG) & (BEV) ?$17!$20, 
2:$20, $11K=1, :$8,$12 K=2, :$8, $13K=3, 
:$8, $14 K=4, :$8, $15 K=5, :$8, $16K=6, 
2$8, $17K=7, :$8, $20; 


An additional phrase is added to the system 
to provide control for printing of results. 


PHRASE: ADD PHRASE: ANSWER, (30)BASE-, 
RISE-, SLOPE-, ANGLE-, BEVEL-, 
(38) ALL-, (40) "BASE =", (45) 
"RISE =‘, (50) ‘SLOPE =", (55) 
‘ANGLE =", (60)"BEVEL =", 1(39) 
N5, PROGRAM*PRINT'; 

FUNCTION: This phrase allows a user to 


request results by entering a 
request for answers and indicat- 
ing the items to be printed. An 
entry of ALL indicates that all 
five values are to be printed. 
The alphameric constants are 
provided as phrase-defined 
literals. The PRINT program is 
to be placed into the pop-up 
list each time the ANSWER phrase 
is encountered. 


7.3.0 PROGRAMMING 


This section provides the code for the 


FORTRAN modules CALC, PRINT, and CSERR. 
Cc THE NAME OF THIS PROGRAM IS CALC 
Cc IT PROVIDES TRIANGLE SOLUTIONS 
C | DEFINE PLAN PROTECTION COMMON 


COMMON L(625), LS(15), M(255) 
EQUIVALENCE (BASE,M(10)), (RISE,M(11)) 
1, (SLOPE,M(12)), (PBEVE,M(82)), 
2(PBASE, M(70)), (PRISE, M(73)), 
3(PSLOP, M(76)), (PANGL, M(79)), 
4(ANGLE, M(13)), (BEVEL,M(14)), 
5LS(8)), 

BASE = 
RISE = 
SLOPE 


(MX, 


PBASE 

PRISE 

( PSLOP 
ANGLE = PANGL 
BEVEL = PBEVE 

c DETERMINE WHICH VALUES ARE GIVEN 
K2=-1 

c SET LOOP TO CHECK FIVE VALUES 
DO 5 I=10,14 

Cc IS VALUE FALSE 
IF (NDEF(M(I)))5,5,10 


Aq fa aA An Aa Ankh Ak AT AAMAAANAAA AANAN 


wn 


10 


15 


20 


25 
30 


35 


40 
45 


55 


60 


65 


70 


75 


80 


85 


90 
95 


100 


105 
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SEE 
USE" 
CONTINUE LOOP 

CONTINUE 

IF LOOP FALLS THROUGH TRI SOL COMMAND 
HAS ERROR 

RETRIEVE DUMP LITERAL AND EXECUTE AS 
COMMAND 

LITERAL PLACED IN ERASABLE COMMON 
EXECUTE COMMAND TO DUMP 
COMMUNICATION ARRAY 

CALL PUSH (M(MX) ) 

IS THIS FIRST DEFINED VALUE FOUND 

IF (K2) 15,20,20 

SET TO SECOND INDEX 

K2=0 

SAVE FIRST VALUE INDEX 

Ki = I-9 

IS INDEX VALID 

IF (K1-4) 5,6,6 

SAVE SECOND VALUE INDEX 

K2 = I-9 

SELECT ON FIRST VALUE 

GO TO (25,30,35),K1 

BASE IS KNOWN 

SELECT ON SECOND VALUE 

GO TO (6,40,60,65,75) ,K2 

RISE IS KNOWN 

GO TO (6,6,80,85,95) ,K2 

SLOPE IS KNOWN 

GO TO (6,6,6,100,110) ,K2 

BASE AND RISE ARE KNOWN - CALCULATE 


*“NDEF" UNDER “PLAN SUBROUTINE 


OTHERS 

SLOPE = SQRT (BASE*BASE+RISE*RISE) 
BEVEL = RISE/BASE 

N1 =1 

GO TO 130 

RETURN TO PLAN LOADER 

CALL LRET 


BASE AND SLOPE ARE KNOWN 

RISE = SQRT (SLOPE*SLOPE - BASE*BASE) 
GO TO 45 

BASE AND ANGLE ARE KNOWN 

N1 = 1 

GO TO 120 

SLOPE = BASE/COS (TEMP) 

RISE = SQRT (SLOPE*SLOPE - BASE*BASE) 
GO TO 55 

BASE AND BEVEL ARE KNOWN 

N1 = 2 

GO TO 130 

RISE AND SLOPE ARE KNOWN 

BASE = SORT (SLOPE*SLOPE-RISE*RISE) 
GO TO 45 

RISE AND ANGLE ARE KNOWN 

N1 = 3 

GO TO 120 

SLOPE = RISE/SIN(TEMP) 

GO TO 80 

RISE AND BEVEL ARE KNOWN 

Ni = 4 

GO TO 130 

SLOPE AND ANGLE ARE KNOWN 

N1 = 5 

GO TO 120 

RISE = SLOPE * SIN(TEMP) 

BASE = SLOPE * COS (TEMP) 

GO TO 55 
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Cc SLOPE AND BEVEL ARE KNOWN 
110 N1 = 6 
GO TO 130 
120 TEMP = ANGLE*.0174532965 
GO TO (125,70,125,90,125,105) ,N1 
125 BEVEL = SIN(TEMP) /COS (TEMP) 
GO TO(70, 70,90, 90,105,105), N1 
130 ANGLE = ATAN(BEVEL) *57.2958 
GO TO (55,120,95,120,105,120),N1 


ANAANA 


END 
Cc THE NAME OF THE PROGRAM IS PRINT 
Cc IT PRINTS THE RESULTS OF TRIANGLE 
Cc SOLUTIONS 
COMMON L(625), LS(15), M(255) 
EQUIVALENCE (N,M(39)), (NS,M(38)) 
Cc SET OUTPUT DEVICE BUFFER 
CALL PSBFA(100) 
Cc SET LOOP TO PROCESS FIVE VALUES 
po 15 I =1,N 
Cc ARE ALL VALUES TO BE PRINTED 
IF (NDEF(NS)) 5,10,5 
Cc IS THIS VALUE TO BE PRINTED 
5 IF (NDEF(M(I+29)))15,10,15 
Cc PLACE. DATA NAME IN BUFFER 
10 CALL PAOUT (100,5,M(5*I+35), 
1M(5*1+36) ) 
Cc PLACE VALUE IN BUFFER 
CALL PFOUT (100,6+M(54I+35), 83, 
1M(I+9)) 
Cc WRITE FROM BUFFER 
CALL PLOUT (100) 
15 CONTINUE 
20 CALL LRET 
SINCE A FORTRAN PROGRAM CANNOT END 
WITH A CALL TO A SUBROUTINE, THE 
FOLLOWING DUMMY INSTRUCTION IS 
INSERTED TO SATISFY THE FORTRAN 
COMPILER 
GO TO 20 
END 


The command CSERR is executed if error 
conditions are found while executing the 
TRIANGLE SOLUTION command. The function of 
this command is to set up literal informa- 
tion for logging of errors. 


(1) ‘IS 
ERROR‘, 


ADD PHRASE: 
"IN ERROR‘, 


CSERR, PROGRAM'CSERR‘, 
(25) ‘SPECIFICATION 


I(11)NOD100, (40) "BASE ‘, (45)*RISE ‘, (50) 
(55) "ANGLES, (60) "BEVEL'; 
The module to process the error indicators 


is given below: 


THE NAME OF. THIS PROGRAM IS CSERR 

IT LISTS ERRORS IN TRIANGLE SOLUTION 
DEFINITIONS 

DEFINE PLAN COMMON 

COMMON L(625), LS(15), M(255) 
EQUIVALENCE (K,M(9)), (NOD,M(11) ) 
ESTABLISH BUFFER FOR PLAN DIAGNOSTIC 
DEVICE 

CALL PSBFA(NOD) 

Cc FIND THE ERROR 

LDX = Ktl 


AANA 


aa 
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GO TO (5,25,35,40,45,47,45,50), LDX 
OTHER THAN TWO VARIABLES SPECIFIED 
IN TRI SOL COMMAND 
INVALID. DEFINITION LITERAL 
5 CALL PAOUT(NOD,1,M,M(2)) 
CALL PLOUT (NOD) 
Cc LIST THOSE VARIABLES DEFINED 
DO 15 I = 70,82,3 
c IS ELEMENT DESCRIBED 
IF (NDEF(M(I)))15,10,10 
Cc LIST ITEM 
10 IDX = (I-67) / 3 * 5 + 36 
CALL PAOUT(NOD,5,5,M(IDX) ) 
CALL PLOUT(NOD) 
15 CONTINUE 
c RETURN TO PLAN 
20 CALL LRET 
c BASE IS IN ERROR 
25 CALL PAOUT(NOD,1,5,M(41)) 
30 CALL PAOUT (NOD,7,M,M(2)) 
32 CALL PLOUT(NOD) 
GO TO 20 
c RISE IS IN ERROR 
35 CALL PAOUT (NOD,1,5,M(46)) 
GO TO 30 
c SLOPE IS IN ERROR 
40 CALL PAOUT(NOD,1,5,M(51))) 
GO TO 30 
c ANGLE IS IN ERROR 
45 CALL PAOUT (NOD,1,5,M(56)) 
GO TO 30 
c BEVEL IS IN ERROR 
47 CALL PAOUT(NOD,1,5,M(61)) 
GO TO 30 
c BEVEL ANGLE IS INVALID DEFINITION 
50 CALL PAOUT (NOD,1,5,M(56)) 
CALL PAOUT (NOD,7,5,M(61)) 
CALL PAOUT (NOD,13,2,M(2)) 
CALL PAOUT (NOD,16,M(25) ,M(26)) 
GO TO 32 
END 


aan 


7.4.0 ALTERNATE SOLUTION 


The module CSERR and command CSERR can be 
eliminated altogether by making use of the 
check-entry facility through an expanded 
version of the TRI SOL command. Spaces 
shown in the following example may need to 
be removed to keep the phrase from exceed- 
ing 450 characters. 


ALT PHR: TRI SOL, LEV1, (70) BAS, (73) RIS, 
(76)SLO, (79) ANG, (82)BEV, (20)-: (BAS<O) ?=+, 
-~: (RIS<O) 2=+, -—:(SLO<0) 2?=+, —: (ANG<O) ?=+, 
~: (BEV<0O) ?=+, —: (ANG>90) ?=+t, -: CANG=~) | 
(BEV=—) ?=-!=+, TEST, I(8)J1,N0, ~*P‘CON TRI 
SOL‘, $4:BAS(J)?$5!$6, S$5N=N#1, $6J=J+1, 
: (J=16) ?$7!S4, ST7TTES: (N=2) ?$8!=-, $8; 


ALT PHR:CON TRI SOL, (20)*FA‘BASE NEGA- 
TIVE", | *FA‘ RISE NEGATIVE‘, *FA* SLOPE 
NEGATIVES ,*FA‘ ANGLE NEGATIVE‘, *FA'BEVEL 
NEGATIVE", *FA‘ ANGLE GREATER THAN 90", 
*FA‘ANGLE AND BEVEL MAY NOT BOTH BE 
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DEFINED‘, *FA* INVALID PARAMETER SPECIFICA- 
TION" PRO*CALC'; 
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8.0.0 APPENDIX A: 1130 PLAN SPECIFICATIONS 


This appendix contains additional informa- 
tion about the specifications and use of 
the PLAN system on the IBM 1130 Data 
Processing System. Included is information 
of additional PLAN features that allow a 
user to make better use of features unique 
to the 1130. Note that use of these 
features may create code that is dependent 
upon running within the 1130 version of 
PLAN. Specific references to compatibility 
considerations are provided in Appendix J 
(18.0.0). 


8.1.0 USER EXITS 


User-exit routines for 1130 PLAN must have 
a COMMON statement defined carefully 
according to the formulas shown below: 


If 8K PSCAN is used: 


NFW = (CORE~-1500)/2 


If 16K PSCAN is used: 
NFW = (CORE-2000)/2 
Where: 


NFW is the total number of 32-bit words 
that must be specified in the COMMON 
statement. 


CORE is the machine size (8192, 16,384, or 
32,768) specified by monitor (core 
parameter in monitor load) at the time 
the user module is core-imaged. 


Index register 1 provides a pointer to a 
communication block that may be used by the 
user-exit program, provided that the pro- 
gram is written in the assembly language. 


Displacement Contents of Word(s) Addressed 


0-23 These locations contain link- 
ages to subroutines that may 
be useful in the user-exit 
routine. They are used by a 
linkage of the type: 


BSI xX1 ON 
Dc ARG 


N is the displacement defined 
in this table. Each linkage 
is followed by additional 
information as shown below. 
ARG in the examples is the 
address of the parameter 
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required for the appropriate 
subroutine. 


0 These words provide linkage 
to the floating-point load 
(FLD) routine. 


3 These words provide linkage 
to the floating-point store 
(FSTO) routine. 


6 These words provide linkage 
to the floating-point add 
(FADD) routine. 


9 These words provide linkage 
to the floating-point sub- 
tract (FSUB) routine. 


12 These words provide linkage 
to the floating-point multi- 
ply (FMPY) routine. 


15 These words provide linkage 
to the floating-point divide 
(FDIV) routine. 


18 These words provide linkage 
to the floating-point to 
integer conversion routine 
(IFIX). The floating-point 
number is assumed to be in 
the floating-point accumula- 
tor. The result is placed in 
the accumulator. The DC fol- 
lowing the BSI is replaced 
with a NOP for this linkage. 


21 These words provide linkage 
to the integer to floating- 
point conversion routine 
(FLOAT). The integer is 
assumed to be in the accumu- 
lator. The result is placed 
in the floating-point accumu- 
lator. The DC during the BSI 
is replaced with a NOP for 
this linkage. 


The subroutines described above are further 
defined in the manual IBM Subroutine 
Library (C26-5929). 


Index register 3 must point at the transfer 
vector of the user-exit routine when a CALL 
IUSER is issued. The register will auto- 
Matically be pointed to the PSCAN transfer 
vector (floating accumulator) following any 
linkage on index register 1, as outlined 
above. 
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8.2.0 COMMUNICATION ARRAY SPECIFICATIONS 


COMMON has a maximum allowable size that is 
a function of the machine size and the 
maximum size PLAN module. The maximum size 
communication array for 1130 PLAN using the 


8K version of PSCAN and PERRS is computed 
from the following formula: 

NWDS = (KORE ~—(8192-1020))/2 
The commands "ADD PHRASE:", "ALTER 
PHRASE:", and “DELETE PHRASE:" will cause 
overlay of the communication array. The 
16K versions of PSCAN and PERRS allow 


protection of a communication array as 
defined by the formula shown below, where 
KORE is the machine size of a 16K or 32K 
system. 


NWDS= (KORE- 13056) /2-640 


NWDS is the number of 32-bit words that may 
be contained in the communication array. 


KORE is the number of 1130 machine words in 
the object machine. Simplified, the formu- 
la becomes: 


NWDS = KORE/2-6528 


8.3.0 PROGRAMMING. RESTRICTIONS 


The following 1130 FORTRAN statements 
should not be used because of their detri- 
mental effect on the execution of PLAN. 
Alternate facilities are listed for each 
option. 


To avoid overriding the PLAN processor or 
endangering another user's job, the follow- 
ing 1130 FORTRAN statements should not be 
executed. 


This subroutine call creates 
a premature return to mon- 
itor. A CALL LRET should be 
used instead to return con- 
trol to PLAN. CALL LEXx(1, 0) 
will return control to PLAN 
and clear the pop-up list. 


CALL EXIT 


This statement has the same 
effect as CALL EXIT when 
processing is restarted. 


STOP 


CALL LINK The PLAN loader 
(LRET, LEX, List) must 
replace this call to allow 


PLAN to remain in control. 


subroutines 


The PLAN file routines (FIND- 
READ-WRITE or GDATA-RDATA- 
WDATA) provide for discretely 
addressable, execution-time 
definable files, and should 
be used instead of these 


DEFINE FILE, 
READ (a"b) 
WRITE (a*b) 
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statements. Any function 
disturbing the contents of 
working storage may not be 
intermixed with the execution 
of PLAN dynamic file rou- 
tines. If these files 
reference only files defined 
in the FIXED AREA, they may 
coexist with PLAN file proc- 
essing routines. 


8.4.0 OVERLAY STRUCTURE 


The CALL LOCAL provides one level of pro- 
gram overlay under 1130 PLAN. 


The local program is core-imaged and stored 
by name in the 1130 program library the 
same as any other PLAN module. The program 
must be core-imaged to a fixed address that 
does not jeopardize the calling program. 
The following approach may be used to 
generate the LOCAL modules: 


1. Write FORTRAN module that is to be 
called as a PLAN LOCAL where ddddd 
represents the decimal address of the 
beginning of the executable code. This 
address must allow for 30 words above 
the end of the program issuing the CALL 
LOCAL. 


// JOB 
// FOR 
*LIST ALL 
*ORIGIN ddddd 
COMMON L(625),1LS(15) ,M(510) 
C TEXT OF PROGRAM FOLLOWS 


RETURN 

END 
// DUP 
*DELETE NAMEA 
*STORE WS UA NAMEA 


2. Execute PLAN. 


Note that the variable parameter list pro- 
vided in System/360 OS/DOS PLAN is not 
supportable by 1130 PLAN. 


Each module issuing a CALL LOCAL must allow 
for a 42-word (16-bit) block at the end of 
the load (transfer vector) for the saving 
of the necessary control information. 


8.5.0 IOCS DEVICE PARAMETERS 
Under 1130 PLAN, the I0CS subroutine and 


sequential file subroutines parameters are 
the standard device codes shown below: 
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PLINP PLOUT 
INPUT LIST MEANING 
0 Current PLAN input device 
100 Current PLAN output device 
1 1442 Card Reader 
101 1132 Printer 
2 2501 Card Reader 
102 1403 Printer 
3 1131 Console Keyboard 
103 Console Printer 
104 1442 Punch 


A value of 0 for NOD for the sequential I/0 
routine specifies the PLAN input device and 
100 specifies the current output device. 


Iocs is a level 0 command on 1130 PLAN that 
allows the PLAN input and output devices to 
be altered. 
The general format of the command is: 
Iocs, INPUT n, LIST m; 
a. INPUT. This parameter must. specify 


the input unit that is to be used for 
input of following PLAN commands. 


Valid arguments are 2501, 1442, and 
1131. 
b. LIST. This parameter must specify the 


output unit that is to be used for 
output of following PLAN diagnostics. 
Valid arguments are 1132, 1403, 1442, 
or 1131. 


CARD is a blank-level command on 1130 PLAN 
that allows changing input to either card 
reader and/or output to either line 
printer. 


The general format of the command is: 
CARD, INPUT n, LIST m; 


a. INPUT. This parameter must specify 
the card reader from which the next 
PLAN input is to be read. Valid 
arguments are 2501 or 1442. 


b. LIST. This parameter must specify 
the printer on which the next PLAN 
diagnostic is to be printed. Valid 
arguments are 1403 or 1132. 


TYPE is a blank-level command on 1130 PLAN 
that sets the console typewriter/printer as 
the input/output device from/to which the 
next PLAN input/output is to be _ read/ 
written. (See "PLAN Standard Phrases", 
4.5.0, for a detailed description of this 
command. ) 
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8.6.0 DYNAMIC FILE SUPPORT 


The positions of the NDR parameter to the 
left of the decimal units position are 
treated aS a communication array pointer. 
The contents (16-bit) of the indicated 
communication array are tested against the 
cartridge identification provided by the 
DCIP (disk pack initialization) routine at 
monitor generation time. If the cartridge 
is not found, an error is given. 


The basic unit of allocation for 1130 PLAN 


files is four sectors. This provides 
storage for 628 32-bit words. 
Specification in the CALL FIND of a NALLO 


parameter four-sector 


allocation. 


May override the 


The 1130 PLAN file routines 
changing as defined by the 
specifications: 


allow pack 
following 


1. A cartridge change is not allowed on 


logical drive 0. 


2. The user must assure that packs to be 
dismounted do not contain any required 
program or PLAN file. 


3. The cartridge change may be effected by 
the following subroutine call: 
CALL PLNUP(MPKID,NDR,MCODE,MLDR) 
MPKID This parameter contains the 16-bit 
cartridge identification mask, in 
the range 0001-7FFF (hexadecimal), 
that is used to check the validity 
of the mounted cartridge. 
NDR This parameter defines the logical 
drive number in the range of 0-4. 
This field may also contain a value 
of 100 to specify that the pack is 
to be mounted on the first available 
drive. The resulting drive code is 
returned in the MLDR parameter. 
MCODE This parameter is the return code as 
follows: 
1. Pack successfully mounted 
2. Invalid pack ID or drive code 
3. Current pack cannot be dismounted 
4, Requested pack is already mounted 
on another logical drive. The 
drive number is returned in the 
MLDR parameter. 
5. Operator decided not to mount the 
pack (see “Pack Changing Instruc- 


tions" in the 1130 Operations 
Manual). 

6. Invalid sequence of logical 
drives, for example, logical 


drive 3 is requested, but logical 
Grive 1 and 2 are not mounted. 
7. No available logical drive. If 
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NDR equals 100, ail available 
drives are already mounted. 


MLDR This parameter contains the drive 
code if the pack is mounted 
successfully. 

Note that any monitor (SUP, DUP, FOR, or 


ASM) function that uses working storage on 
a pack on which PLAN files reside may 
result in destruction of those PLAN files. 


8.7.0 PERMANENT FILE SUPPORT 


The file that is processed by GDATA-RDATA- 
WDATA is initially established outside of 
1130 PLAN. One means of establishing a 
file is illustrated in the example shown 
below. Additional information may be found 


in IBM 1130 Disk Monitor System, Version 2, 
System Introduction (C26-3709). 


// DUP 

*STOREDATA WS UA FILE nnnn 

FILE specifies the identification of the 
file by which it is stored (and subsequent- 
ly identified in the GDATA call), and nnnn 
defines the number of sectors that are to 
be assigned to the file. This allocation 
is never changed by PLAN. 


8.8.0 EXTENDED PRECISION SUPPORT 


The following set of subroutines provides 
support for extended precision floating- 


point in the form of conversion subrou- 
tines. PLAN floating-point functions sup- 
port only standard floating-point. Care 
must be exercised if the control card 


*EXTENDED PRECISION is used to adjust com- 
munication array references to adjust for 
the 48-bit word size. It is recommended 
that *ONE WORD INTEGERS be used and that 
COMMON be defined as integer arrays with 
twice the normal word count. 


Special care must be taken when using this 
support to assure that the PLAN loader 
COMMON specification equals 625 32-bit 
words and that the Switch Word COMMON 
specifications equal 15 32-bit words. 


CALL PEXTP (FROM, TO, COUNT) converts a 
standard precision floating-point array 
Starting at FROM, to an extended precision 
floating-point array, starting at TO. The 
number of values converted is specified by 
COUNT. The result is in the following 
form: 
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| | 1 | I | 
| UNUSED | CHARACTERISTIC| S| MANTISSA| MANTISSA| 
a a in ae ces as Sa se wo ec es a sO ce cc ed wap a ee ll cy ome Si aa cs a 


0 “5 8 15 16 17 ae 0 i 
S=Sign of Mantissa 


CALL PENRM (FROM,TO,COUNT) converts an 
extended precision floating-point array 
Starting at FROM, to a standard precision 
floating-point array, starting at TO. The 
number of values converted is specified by 
COUNT. The result is in the following 
form: 


| | { | | 
1s |MANTISSA | MANTTSSA | CHARACTERISTIC | 


0 1 is 16 oa 24 
S=Sign of Mantissa 
CALL PEPCK (FROM, TO, COUNT) packs an 


extended precision floating-point array as 
stored by the PLAN user exit in location 
FROM into array TO in the standard 1130 
FORTRAN array format. COUNT is the number 
of variables to convert. 


CALL PEUPK (FROM,TO,COUNT) expands a stand- 
ard 1130 extended precision array (occupy- 
ing three words per variable) at location 
FROM into a PLAN user exit extended preci- 
sion array (occupying four words per vari- 
able) at location TO- COUNT is the number 
of words to convert. 


CALL PIPCK (FROM,TO,COUNT) packs integer 
data in array FROM stored in PLAN input 
form to array TO. Array TO is in one-word 
integer form. COUNT is the number of 
integers transferred. Formats of FROM and 
TO are given below: 


| | { | | 
| INTEGER | UNUSED | INTEGER | UNUSED | 


FROM 
0 15 Te afl 0 15 ae 31 
| | | 

TO | INTEGER | INTEGER| INTEGER| INTEGER | 
0 ae 16 ae 0 ee 16 a1 


CALL PIUPK(FROM,TO,COUNT) expands a stand- 
ard one-word integer array to standard PLAN 
input format. The formats of the FROM and 
TO arrays are exchanged as shown in the 
above example. 


PLAN USER EXIT 1 (EXIT1) is utilized 
through a routine that will allow collec- 
tion and conversion of input data in 
extended precision. 


The resultant numbers 
communication array on 


are placed in the 
even-word bound- 
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aries, starting at the location specified 
in the phrase definition. The extended 
precision number is stored in two adjacent 
normal precision 32-bit word locations. 
The format of the result is: 


{ | 1 1 I | i 
{UNUSED| Cc {| S|MANTISSA|MANTISSA| UNUSED] 
eae a a ron NERC! Elenite am Uae a ore i nee eee 4 
0 7 8 15 16 17 31 0 15 16 31 
C=Characteristic of Number 
S=Sign of Mantissa 


8.9.0 EXPANDED LOADER FUNCTIONS 
Two 


porary use of the loader overlay area 
temporary data storage. 


subroutines are provided to allow tem- 
for 


CALL LSAV saves the current status of the 
loader area, including the switch area (540 
FORTRAN words), exclusive of the bootstrap 
area. CALL LSAV must be issued before data 
is stored in the loader area. Control 
returns to the next statement after CALL 
LSAV. 


CALL LRLD must be used to restore the saved 
status of the loader before any other call 
to a PLAN loader function, after a CALL 
LSAV has been issued. Control returns to 
the next instruction after CALL LRLD. PLAN 
loader functions include CALL ERRET, CALL 
ERRAT, CALL ERROR, CALL ERREX, CALL GDATA, 
CALL RDATA, CALL WDATA, CALL INPUT, CALL 
PHIN, CALL PUSH, CALL PHOUT, CALL GDAT1, 
CALL WDAT1, CALL RDAT1, and all routines 
prefixed with an L. 


8.10.0 SYSTEM FILE DEFINITIONS 


Two optional files are used by 1130 PLAN. 
They are PDATA and PCHPT. This section 
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method of computing the 


required file size in sectors. 


File: 
Required if: 


Size Rqd: 


File: 
Required if: 


Size Rqd: 


PDATA 
Level 2, level 3, or level 4 
phrases are used and Switch 


Word 10 is nonzero (data is to 
be managed by levels) or CALL 
PSORT or CALL PMERG functions 
are used. 

(M+159)/160*3, where M is’ the 
size of the managed array as 
defined by Switch Word 10. 


In addition, 
where L is the size of the 
communication array (words 
must be provided) if PSORT/ 
PMERG are used. 


(L+159)/160, 


PCHPT 

CALL LCHEX is used, if abnorm- 
ally large numbers of errors 
result in an overflow of the 
error stack, if the IMMEDIATE 
option for error processing is 
used, if a user module is used 
to process errors or if PSORT 
and PMERG are used. Although 
PLAN will operate in many 
environments without a check- 
point file, it is recommended 
that the system contain room 
for at least one checkpoint 
level. 

DB*16/320, where DB is the sum 


total of disk bytes used by 
the programs (those to be 
checkpointed simultaneously) 


when they were stored in the 
program library. 
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9.0.0 APPENDIX B: 


This appendix contains additional informa- 
tion about the specifications and use of 
the PLAN system on the IBM System/360 under 
the Disk Operating System. Included is 
information of. PLAN features that allow a 
user to make better use of features unique 
to the Disk Operating System. Note that 
use of these features may create code that 
is dependent upon running within the 
System/360 DOS version of PLAN. Specific 
references to compatibility considerations 
are provided in Appendix J (18.0.0). 


9.1.0 DOS/360 PLAN SYSTEM 


initiated as a 
in execution it 


The DOS PLAN system is 
DOS/360 job step. Once 


assumes the responsibility of loading other | 


problem program load modules within the 
partition. PLAN must be run in the back- 
ground partition. 


| FORTRAN 
| I/O AREA 


PLAN SYSTEM 
WORK AREA 


I 
PLAN I 
| 
| 


Figure 14. DOS PLAN storage utilization 
The PLAN system is a part of blank COMMON. 
It is 2560 bytes long (640 32-bit words). 
Every module loaded by PLAN must have a 
blank COMMON control section and must pro- 
tect this area with a dummy array at the 
beginning of COMMON. 


The program area starts at the top of blank 
COMMON and extends upward to the PLAN 
system work area. All modules joaded by 
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PLAN must be link-edited so that they fall 
entirely-in this area. 


The PLAN system work area contains PLAN 
tables and I/O buffers required to perform 
all PLAN I/O operations. The size of this 
area is variable, ranging upward from a 
minimum of approximately 3500 bytes. 


The user work area iS an array declared at 
PLAN initialization time. Its address, if 
present, is passed to every module loaded 
by PLAN. The default length of this area 
is zero. 


The FORTRAN I/O area is an array declared 
at: PLAN initialization time. This array is 
used by the FORTRAN {[I/0 package for I/0 
areas, etc. This area must contain at 
least 512 bytes if FORTRAN I/O is used. 
The default length of this area is zero. 


9.2.0 COMMON CONTROL 


COMMON is managed and referenced in DOS 
PLAN according to the following procedures. 


1. The PLAN subroutines reference COMMON 
through a blank COMMON control section 
Of 640 words. 


2. The length of COMMON may be altered 
whenever a mainline (NON-LOCAL) module 
is loaded. PLAN Switch Word 9 controls 
the minimum length of COMMON. All 
modules loaded by PLAN must have a 
COMMON control section at least as long 
as the value specified in Switch Word 
9. 


9.3.0 PROGRAM AREA CONTROL 


All modules loaded by PLAN must meet the 
following requirements: 


1. A COMMON control section at least as 
long as the value currently in Switch 
Word 9. 


2. The module must be link-edited so that 
it falls entirely within the program 
area. 


3. Modules to be loaded as LOCALS must be 


link-edited so they do not overlay the 
calling module. 
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9.4.0 USER-EXIT PROGRAMMING 





The PSCAN user-exit program must be written 
to expect the standard System/360 FORTRAN 
subroutine linkage conventions. 


The user-exit program must be link-edited 
so that its origin is above the end of the 
PLAN module DFJPSCAN. 


9.5.0 COMMUNICATION ARRAY SPECIFICATION 


The size of COMMON protected from overlay 
by PLAN modules is 640 32-bit words plus 
the amount added to the origin of PLAN 
system modules at the time they are Link- 
edited (See "Generating a Tailored PLAN 
System" in the DOS PLAN Operations Manual). 
Data will not be stored by PSCAN into the 
communication array beyond the smaller of 
(1) the origin of PSCAN or (2) the value 
contained in Switch Word 9. PSCAN will 


give an error diagnostic and abort if an 
attempt is made to store beyond these 
limits. 


9.6.0 PROGRAMMING RESTRICTIONS 


The following System/360 FORTRAN statements 
should not be used because of their detri- 
mental effect on the execution of PLAN. 
Alternate facilities are listed for each 
option. 


This subroutine call creates 
a premature return to the DOS 
supervisor. A CALL LRET 
should be used instead to 
return control to PLAN. CALL 
LIST(1,0) will return control 
to PLAN and clear the pop-up 
list. 


CALL EXIT 


This statement has the same 
effect as CALL EXIT when 
processing is restarted. 


STOP 


CALL DUMP This statement creates a pre- 
Mature end to the PLAN execu- 
tion. Therefore, the CALL 
PDUMP, followed by a CALL 


LRET, should be used. 


Any PLAN module that issues a CALL LNRET 
must exit by a PLAN loader call (may not 
use a RETURN statement). 


9.7.0 CORE MANAGEMENT 


The PLAN loader provides management of core 
assignment to allow coexistence of 
independently written, functionally depen- 
dent pieces of code. 
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The user is provided with special arguments 
that, when encountered in the pop-up list, 
indicate the limits of the functionally 
dependent modules. The left parenthesis 
indicates the start of a string of module 
names for which the user desires coexistent 
residence. The right parenthesis indicates 
the end of the string. Figure 15 repre- 
sents the pop-up list containing a list of 
programs. Programs M0716 through M0725 are 
to be grouped in memory concurrently. 


: 
|MO712| 
|MO756| 
| ¢ | 
{M0716 
{M0796 | 
|MO732| 
{MO725| 


Figure 15. Loader pop-up list 


The systems programmer in determining the 
scheduling control, that is, which modules 
may coexist within the partition, must 
recognize and/or account for the following 
conditions: 


1. If more modules are grouped (bounded in 
the pop-up list with parentheses) than 
can coexist, those modules that will 
not fit are not loaded concurrently. 


2. If space can be found, all parentheti- 
cally grouped modules are loaded into 
the partition. Entry is made to the 
first program named after the left 
parenthesis. 


3. Loading of a module results only if the 
module does not already exist in 
memory. 


4. If the left/right parenthesis is 
encountered when entering data into the 
pop-up list without a corresponding 
right/left parenthesis, the unmatched 
parenthesis is ignored. Therefore, 
parenthetically grouped programs must 
be added to the pop-up list with a 
Single loader subroutine call. 


5. If the left or right parenthesis is to 
be inserted in the pop-up list, it must 
be left-justified in two FORTRAN words. 


6. Program lists, verb lists, and check- 
entry program lists include the paren- 
thetical groupings in literal form. 
Example: 
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wee,PROGRAMS ‘M0713, 
M0792), M0796",..+- 


(M0726, M0733, 


7. The combination of the parenthetical 
program grouping and the use of command 
input of program lists gives the user 
the power to add segments (modules) to 
his root structure at execution time. 


8. If all programs indicated in the coex- 
istent grouping cannot be loaded 
because of conflicting core residence 
requirements (programs should be link- 
edited so they do not overlay each 
other) the right parenthesis is floated 
forward in the list to include those 
programs for which coexistent loading 
was accomplished. 


The original right parenthesis is 
deleted and a right parenthesis is 
regenerated in the pop-up list at a 
position that indicates the last pro- 
gram which was successfully loaded. 


9. A negative call to the program linkage 
routines (value of N is negative) is 
required to interrogate the pop-up list 
for successful loading of the coexis- 
tent programs. 


10. Parenthetical grouping is acceptable 
but ignored on the 1130 version of 
PLAN. 


11. All program lists to be inserted into 
or to be extracted from the pop-up list 
must begin on a full-word boundary. 


9.8.0 RETURN LINKAGE 
The FORTRAN RETURN statement functions 


exactly like the CALL LRET PLAN loader 
call. Register 14 is used to cause a 
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return from the logic module to the PLAN 
loader. PLAN modules that contain CALL 
LNRET may not exit via RETURN. FORTRAN 
subroutines which modify variables passed 
to them as arguments must use the FORTRAN 
RETURN statement. 


9.9.0 OVERLAY STRUCTURE 


The System/360 DOS PLAN System provides a 


local overlay structure that provides the 
mechanism for common usage of multiple- 
purpose control sections. This type of 


processing is typified by an application in 
which the mainline serves only to provide 
linkage to logic segments that perform 
specific functions, and provides the basic 
hardware routines. 


The following logic module is considered 


appropriate for an application of the type 
listed above. It is assumed in the example 
that a command would initially load the 
example module and define the local tasks 
to be completed by entries in the pop-up 
list. 


EXTERNAL ARG1, ARG2,... 

1 CALL LOCAL(0,0,ARG1,ARG2,...,ARGN) 
GO TO 1 
END 


The local module would then be written in 
the following form: 


SUBROUTINE NAME 
CALL ARG1(X,Y,Z) 
CALL ARG2(P,0,R) 


RETURN 
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1 R 
SS ee 1 = es 
| |} R | 
| 1 CALL LOCAL(0,0,A,B) | 1 x | 
| GO TO 1 | | Zz J 
.--------- —{—--> SUBROUTINE A | i an | 
| (----t----- RETURN | | o | 
| | | r-> SUBROUTINE B | LJ 
| | | | RETURN | | INITIAL 
| | | | | | LOAD LIST 
! { I of I | 
{ I i | | l 
{ | | | I | 
| I = SSS eee ? 
| { | I | 
I | | | | 
| | { | | 
cis a yc, Sms a cic 1 
1 | | i | | | 
1 | | 1 | I { 
2 x| | { 3 Z| | l 4 ¥ | 
ees Neaat tS), ets acca SSS 1 
{ { ee ee 1 | [ : | 
| [ Lok ps 1 of [ . | 
| CALL A <‘_ | | |CALL B < 4 [ | CALL LIST (2,A) | 
OVERLAY | ° 1 | ° | | e 
AREA | . i | . | { : | 
| CALL LRET | | CALI. LRET 1 | CALL LRET | 
ee eee oe BB 4 bossa eS 4 
Figure 16. DOS overlay structure 


Return from the LOCAL immediately loads the 
next module indicated in the pop-up list 
until the list is found to be empty. At 
that time, control is given to PSCAN for 
processing a new command. The logic module 
shown in the above example would incorpor- 
ate all multiple-use subroutines required 
by the local modules. 


The use of CALL LOCAL in a source program 
suggests detailed knowledge of an installa- 
tion's core storage boundaries. There must 
be room enough for all load modules that 
are implied by any sequence of CALL LOCALS 
without intervening RETURNS. Since core 
use is an installation variable, it is not 
good practice to use CALL LOCAL in general 
purpose modules. This call is designed for 
root modules containing shared subroutines 
to use in invoking a hierarchical overlay 
scheme. 


A program module that has issued CALL 


LOCALs and has not regained control may not 
be the object of another CALL LOCAL. 


9.10.0 PLAN SYSTEM CHECKPOINT 
The following regulations govern execution 


and control of the checkpoint facility 
within the OS version of PLAN (CALL LCHEX): 
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Checkpoints can be reloaded only within 
the limits of the phrase from which 
they were written. This means that any 
checkpoint that has not been reloaded 
when the end of the phrase is encoun- 


tered -- that is, when the pop-up 
loader is found to be empty -- is 
destroyed. No warning message is 
issued. 


If the checkpoint return (*) is encoun- 
tered while in local mode, the local 
processing is terminated and the check- 
point is reloaded. 


Any input/output error while reading or 
writing the checkpoint data set results 
in a phrase abort, and PLAN level error 
recovery is initiated. This action is 
also true when insufficient space is 
available in the checkpoint data set. 


The DOS checkpoint facility has a 
unique feature that enables the PLAN 
subroutine LCHEX to function ina man- 
ner similar to the LOCAL facility. 
This is accomplished by not actually 
writing a checkpoint when requested but 
instead marking all modules in the 
program area as ready to be check- 
pointed. Any time a program that is 
marked as such is about to be overlayed 
by the loading of another program, the 
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physical write to the checkpoint file 
takes place. This allows the user to 
take advantage of additional core 
without reprogramming modules that use 
LCHEX by relink-editing the modules 
called by LCHEX. 


5. There is no logical restriction on the 
number or level of checkpoints that a 

. user may execute. A physical limit 
based on the size of the checkpoint 
data set may produce a real limit or 
error condition as outlined in 3 above. 


6. Checkpoint restarts are executed ina 
reverse order from which they are writ- 
ten, that is, last in-first out. 


7. After a checkpoint is taken, the status 
of all data sets except system data 
sets (those data sets processed by CALL 
PLINP, CALL PLOUT, CALL GDATA, and CALL 
FIND) must not be altered until the 
checkpoint is restarted. This is a 
user responsibility and no_ check is 
made by PLAN to prevent such an altera- 
tion. If a data set status is altered 
while a checkpoint is in effect, the 
results are unpredictable. 


8. COMMON is not protected between the 
time that a checkpoint is taken and the 
restart is loaded. It is the user's 
responsibility to save and reload those 
parts of COMMON that might be destroyed 
and that must be present for continued 
execution of the checkpointed module. 


9. Floating-point registers are not 
restored when a checkpoint is 
restarted. 


9.11.0 DYNAMIC FILE SUPPORT 


The NALLO parameter provided with CALL FIND 
is used to optimize space allocation. The 
basic unit of allocation for an DOS PLAN 
file is 1350 32-bit words. 


The positions of the NDR parameter other 
than the units position are not interro- 
gated by DOS PLAN. Each logical file can 
contain up to 147 discontiguous aliloca- 
tions. Thus, if normal allocation is 
allowed as the file is written, the maximum 
file size is restricted to 220,500 32-bit 
words. If the NALLO parameter of the CALL 
FIND subroutine is utilized, the maximum 
file size is 49,150,350 32-bit words. 


Each logical drive may contain a maximum of 
149 discontiguous free areas. This means 
that in cases. of extreme discontiguous 
allocation a file may be destroyed. 
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9.12.0 PERMANENT FILE SUPPORT 
The DOS version of PLAN provides support 
for files established outside of PLAN with 
the following characteristics: 


1. Files are limited to one extent. 


2. Files must be organized as a sequential 
or direct access file. 


3. Physical records are fixed length. 


4. Track overflow feature may not be used. 


5. There may be no truncated records. 


6. There may be no keys. 
7. There may be no control characters. 


8. The extent must be 


boundaries. 


on cylinder 


9. The entire extent must contain for- 


matted records. 


The file is initially established by a 
user-written routine using an access 
method. The RDATA/WDATA subroutines read 


the file to establish the format 
size) for the file. 


(record 


9.13.0 IOCS DEVICE PARAMETERS 


Under System/360 DOS PLAN, INPUT and LIST 
correspond to sequential devices defined at 
PLAN initialization time. See the DOS 
Problem Language Analyzer (PLAN) Operations 
Manual (H20-0597) for additional informa- 
tion on the definition of PLAN data sets. 


9.14.0 SEQUENTIAL FILE. SUPPORT 


The following steps outline the manner in 
which certain special conditions are 
handled on the DOS/360 version of the 
sequential I/O subroutines (PLINP/PLOUT/ 
PEOF/PCCTL) . 


Two subroutines are provided under DOS PLAN 
that allow specification of page length and 
status switching (CLOSE) for PLINP/PLOUT 
data sets. 


CALL PPAGL(NOD,N) is a subroutine used to 
specify the number of lines to be used as 
the page length for those data sets con- 
taining printed output, 


A call to PPAGL sets the current line count 
to the page length specified. It also 
forces the next carriage control operation 
to be a skip to 1 unless overridden by an 
intervening call to PCCTL. If Nis 0, a 
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default of 60 is used. 
of N is 32,767. 


The maximum value 


CALL PENDF(NOD) is a subroutine that may be 


used to close a sequential data set. Ifa 
data set is in output status, an EOF is 
written after the last record. Both PLINP 


and PLOUT data sets are repositioned to the 
beginning of the data set. 


1. Maximum record size for any input/ 
output record is 32,760 characters. 


2. Records may be blocked within the phys~- 
ical limits of the specified device. 


3. A PLINP/PLOUT call to an invalid device 
is ignored. 


4. In order to effect carriage control, 
that is, for PCCTL to be functional, 
the CCTRL option must be specified for 
the data set at PLAN initialization 
time (see "PLAN System Initialization" 
in the DOS PLAN Operations Manual). 


5. The following items are 
for the PEOF routine: 


specifications 


a. Logical EOF is set when: 

(1) A “UREND" is read by CALL PLINP. 
The logical EOF will be reset by 
the next CALL PLINP to the data 
set. 

(2) The line count is zero for out- 
put data sets (CALL PLOUT) using 
the CCTRL option. 


b. Physical EOF is set when: 
(1) PHYSICAL EOF is read by a CALL 
PLINP. 
(2) A CALL PLINP is issued to a 
device not capable of input. 
(3) A CALL PLOUT is issued toa 
device not capable of output. 
c. A CALL PLOUT is issued to a data set 
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in input status (a CALL PLINP had 
previously been issued). 

d. A CALL PLINP is issued to a data set 
in output status (a CALL PLOUT had 
previously been issued). 


6. The following specifications pertain to 
the carriage tape simulation functions 
on an output device (CALL PCCTL): 


a. The maximum page length is 32,767 
lines. 

b. Default page length is 60 lines. 

c. If the CCTRL option is specified, a 
line count is maintained and an 
automatic eject (skip to carriage 
channel 1) is set when the line 
count reaches zero. 

d. Maintenance of the line count is 
suspended when a CALL PCCTL is 
issued for a skip to channels 2-12. 

e. Maintenance of the line count is 
resumed when a CALL PCCTL is issued 
for a skip to channel 1. 


A PLAN utility program, DFJPLENG, allows 
the user to set the page length to be used 
on an output file that is to contain data 
to be printed. This utility must be 
invoked by the standard PLAN command. 


SET PAGE LENGTH, NOD xxx, PGL yyyyy; 


where xxx is a number up to three digits 
equivalent to the NOD argument for the 
subroutines PLINP and PLOUT, and yyyyy is a 
number up to five digits to be used as the 
page length for the specified NOD. 


9.15.0 PERMANENT FILE SORT/MERGE 


CALL GSORT(ID) and CALL GMERG(ID,JD,KD) 
provide the identical functions for PER- 
MANENT files as CALL PSORT and CALL PMERG 
do for DYNAMIC files. 
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This appendix contains additional informa- 
tion about the specifications and use of 
the PLAN system on the IBM System/360 under 
the Operating System. Included is informa- 
tion of PLAN features that allow a user to 
make better use of features unique to the 
operating system. Note that use of these 
features may create code that is dependent 
upon running within the System/360 OS ver- 
sion of PLAN. Specific references to 
compatibility considerations are provided 
in Appendix J (18.0.0). 


10.1.0 0S/360 PLAN SYSTEM (LOADER) 


The PLAN system is initiated by an 0S/360 
job step. Once in execution it assumes the 
responsibility of loading other problem 
program load modules within the partition 
or region. 


Figure 17 illustrates the PLAN system use 
Of main storage. 
poo - 4*-TOP OF PARTITION 
{| PLAN SYSTEM | 
{| WORK AREA { 
a 
| MANAGED { 
| FREE STORAGE | 
or 
{| NONMANAGED | 
| FREE STORAGE | 
{ I 
ieee | Of 
| PROGRAM | 
| AREA | 
| | 
{---------—----- : 
I | 
| I 
| COMMON | 
| | 
{ | 
be ey ee 
| { 
1 PLAN | 
| SYSTEM | 
| | 
Ree et J 


Figure 17. OS PLAN storage utilization 

The PLAN system is a part of blank COMMON. 
It is 640 32-bit words long. Every load 
module that contains a blank COMMON control 
section must protect this area with a dummy 
array at the beginning of COMMON. 
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The total PROGRAM/COMMON area is under 
control of the PLAN system. Within this 
area, load modules are located as high as 


possible. The size of COMMON is variable. 
It begins at the bottom of the partition 
and extends towards the programs loaded at 
that time. The default length of the 
PROGRAM/COMMON area is 66 per cent of the 
partition/region size. 


The Managed and Nonmanaged Free Storage 
areaS are used to honor GETMAIN requests 


from problem programs. By default the size 


of the Nonmanaged Free Storage area is 
zero. 
The PLAN system work area contains PLAN 


tables and I/O buffers required to perform 
all PLAN I/O operations. This area ranges 
upward from 3K bytes, depending upon: (a) 
use of the RAM and LINKPAC areas for 
reentrant modules and access methods, and 
(b) the number of optional data sets used 
by the PLAN job. 


The length of the PROGRAM/COMMON area and 
the nonmanaged free storage area may be 
varied by the user at execution time 
through EXEC card parameters. 


10.2.0 COMMON CONTROL 


COMMON is managed and referenced in Systen/ 
360 OS PLAN according to the following 
procedures: 


1. The PLAN loader subroutines reference 
COMMON through a “BLANK COMMON" control 
section of 2560 bytes. 


2. The PLAN loader, when loading modules, 
deletes the “Blank Common" control sec- 
tion from the module and modifies 
“Blank Common" references to point to 
PLAN COMMON. 


3. The length of COMMON may be altered 
whenever a new load module is brought 
into core. It will be as long as 
required by any resident load module 
and never shorter than the length spec- 
ified as a data variable in the loader 
Switch Word 9. 


4. For those languages that cannot gener- 
ate a BLANK COMMON CSECT, a virtual 
type ADCON referencing the name "PLANB- 
COM" will be resolved to point to PLAN 
COMMON. The load module containing 
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these references must not contain an 
actual CSECT named PLANBCOM. 


10.3.0 PROGRAM AREA CONTROL 


One or more load modules that are brought 
into core by a single loader entry form one 
program segment. 


The PLAN system manages the program area by 
segment level. When PLAN is requested to 
load a module not in core, all segments in 


memory, assigned a segment level greater 
than the segment level of the module issu- 
ing the loader call, are released. This 
allows overlay processing but does not 
require overlay definition and link 
editing. 


10.4.0 OS FREE STORAGE CONTROL 


The PLAN system maintains several pointers 
concerned with the MANAGED FREE STORAGE 
area. Whenever a program segment is 
released, the system uses these pointers to 
perform the following maintenance: 


1. DELETE modules that the segment loaded 
via the LOAD macro. 


2. Close data sets that were left open by 
the segment. 


3. Use the FREEMAIN macro to release all 
core obtained by the segment's use of 
the GETMAIN macro. 


The user must be aware of the implications 
of the above maintenance procedures. 
Programs that reside in lower-level 
(higher-segments) that are called as LOCALS 
may issue the GETMAIN macro only for tem- 
porary use. Whenever a segment is 
released, all areas in MANAGED FREE STORAGE 
obtained by the GETMAIN macro are released. 
This includes both the segment and all 
modules or subroutines called as LOCALS by 
the segment. 


If a NONMANAGED FREE STORAGE area is 
declared, it is the user's responsibility 
to maintain this area. 


The use of managed or nonmanaged FREE 
STORAGE is controlled by a PLAN system 
indicator that may be dynamically 
controlled by the user through use of the 
PLAN utility modules DFJUMC and DFJUNC. 
Invoking module DFJUMC informs the PLAN 
system that managed free storage is to he 
used to honor GETMAIN macro requests; 
DFJUNC causes PLAN to effect the use of 
nonmanaged free storage to honor GETMAIN 
requests. Either of these routines may be 
invoked as a subroutine, by a CALL LOCAL, 
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or aS a PROGRAM entry associated with a 
phrase. 


10.5.0 PROGRAM USE OF FREE STORAGE 


Two subroutines are provided to allow the 
user to control the area of OS FREE STORAGE 
that is used to honor GETMAIN requests. 


CALL DFJUMC sets the system status to 
indicate that the managed area of OS FREE 
STORAGE is used for GETMAINs. 


CALL DFJUNC sets the system status so that 
the nonmanaged area of OS FREE STORAGE is 
used for GETMAINs. 


10.6.0 PROGRAM AREA MANAGEMENT 


The PLAN loader provides management of core 
assignment to allow coexistence of 
independently written, functionally depend- 
ent pieces of code. 


The user is provided with special arguments 
that, when encountered in the pop-up list, 
indicate the limits of the functionally 
dependent modules. The left parenthesis 
indicates the start of a string of module 
names for which the user desires coexistent 
residence. The right parenthesis indicates 
the end of the string. Figure 18 repre- 
sents the pop-up list containing a list of 
programs. Programs M0716 through M0725 are 
to be grouped in memory concurrently. 


1 

|MO712| 
[M0756 | 
jc | 
{MO716| 
[M0796 | 
[M0732 | 
|MO725| 


Figure 18. Loader pop-up list 

The systems programmer in determining the 
scheduling control, that is, which modules 
may coexist within the partition, must 
recognize and/or account for the following 
conditions: 


1. If more modules are grouped (bounded in 
the pop-up list with parentheses) than 
can coexist, those modules that will 
not fit are not loaded concurrently. 


15 SEPTEMBER 1969 


If space can be found, all parentheti- 
cally grouped modules are loaded into 
the partition with the entry to the 
program named following the left 
parenthesis. 


Loading of a module results only if the 


module does not already exist in. 
memory. 
If the left/right parenthesis is 


encountered when entering data into the 
pop-up list without a corresponding 
right/left parenthesis, 
parenthesis is ignored. Therefore, 
parenthetically grouped programs must 
be added to the pop-up list witha 
single loader subroutine call. ; 


“If the left or right parenthesis is to 


be inserted in the pop-up list, it must 
be “left-justified in two 32-bit words. 


Program lists, verb lists, and check- 
entry program lists include the paren- 
thetical groupings in literal form. 
Example: 


«seePROGRAMS ‘M0713, 
M0792), M0796",... 


(M0726, M0733, 


The combination of the parenthetical 
program grouping and the use of command 
input of program lists gives the user 
the ability to add segments (modules) 
to his root structure at execution 
time. 


If all programs indicated in the 
coexistent grouping cannot be loaded 
because of insufficient partition size, 
the right parenthesis is floated for- 
ward in the pop-up list to include 
those programs for which coexistent 
loading was accomplished. 


The original . right parenthesis is 


deleted and a right parenthesis is 
regenerated 


in the pop-up list at a 
position that indicates the last pro- 
gram which was successfully loaded. 


A call with a negative value of N is 


required to interrogate the pop-up list 


‘for successful loading of the coexist- 


10. 


11... 


ent programs. 


Parenthetical grouping is acceptable 
but ignored on the 1130 version of 
PLAN. . 


The left and right parentheses and all 
programs associated with the indicated 
coexistent grouping must be added to 
the pop-up list with a single call to 
the PLAN loader subroutines, or both 
parentheses must be included in a 
phrase-defined program list. 


the unmatched: 
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12. All program lists to be inserted into 
or to be extracted from the pop-up list 


must begin on a full-word boundary. 


13. Use of xXCTL is prohibited in PLAN 
modules. The use of LINK or ATTACHED 
is allowed. Any program that is 
"linked" to by a module loaded by the 
PLAN loader may use the XCTL, LINK, or 
ATTACH macros. The linked-to program 
may also be in overlay mode. 


The “overlay structure" is not. sup- 
ported in PLAN modules, except as 
defined in 13. 


14. 


not be in 
or - contain 


Modules loaded by PLAN may 
overlay or scatter mode 
TESTRAN symbol cards. 


15. 


16. Load: modules must be marked as execut- 


able by the link editor. 


Load modules may simply succeed one another 
serially in the program area, occupying a 
minimum amount of core; or they may reside 
in core together in a manner similar to 
that supported by the 0S/360 overlay 
supervisor. 


The principal feature of PLAN loading is 
that load modules sharing core do not have 
to be link-edited together. One or more 
load modules that are brought into core by 
a single loader entry form one segment. 


If a CALL LOCAL is issued during execution 
of a program within a segment, the loader 
does not release the calling segment. It 
attempts to. load the new segment into the 
program area. This process may continue 
through several levels, as long as core is 
available. Failure to load a module that 
must be immediately entered will generate a 
PLAN diagnostic and allow the next PLAN 
statement to be executed. Failure to load 
a module that does not have to be entered 
immediately causes the left-hand parenthe- 
sis to be moved as indicated in step 8 
above and execution continues. 


CALL LOCAL does not immediately free 
storage; but the space used by inactive 
segments will be reclaimed if needed by the 
loader. Thus, modules that CALL one anoth- 
er in a loop can share core and execute . 
with maximum efficiency, if they all fit 
within the available region. 


The loader keeps’ track of RETURNs, CALLS 
outside of a load module, and CALL LOCALS 
to allow proper release and acquisition of 
space for load modules. The term "execu- 
tion level" is defined as the number of 
CALL LOCALs that have not been canceled by 
RETURNS. The segment level is the "depth" 
of segments within the program area. 
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If names are parenthesized in the pop-up 
list, all load modules named inside the 
parentheses are treated as one segment. 


The following narrative discusses the 
method used by OS PLAN for program area 
control and management. 


Initial entry to the loader (Figure 19) 
finds the pop-up lists as shown. Paren- 
theses call for three modules to form one 
segment. Program area now appears as shown 
in Figure 19(a). Module A is entered. The 
execution level is 1 (no CALL LOCALs yet). 
During its run, A issues a CALL LOCAL, 
transferring the names. D and E in paren- 
theses to the pop-up list as shown in 
Figure 20. Note that the name of A was 
removed from the pop-up list when it was 
loaded. Execution is at level 2. (A CALL 
LOCAL was issued. ) . 


=A c"- cee) Seas | 
| (A | MODULE A | | 
(Pee DE Rene oe at | 
{ BI | MODULE B | }--> SEGMENT 1 
| | Reser agi | 
{| cI | MODULE Cc | | 
[| o | j-—~---~——— t-—— 
t——— | | 
| | 
herent 
| COMMON | 
be ee J 
Figure 19. Initial entry to loader 


Figure 19(a). Contents of program area 

D is now at the top of the pop-up list but 
not in core. Since D was accessed by CALL 
LOCAL, it will be loaded as an additional 
segment in core. Parentheses define E in 
the same segment. Core now looks’ like 
Figure 19(a). Control passes to D at its 
entry point. D issues a CALL LOCAL without 
changing the pop-up list. 


ae | cc Sess 1 
| @m | I I 
| £) | | SEGMENT 1 | 
1 B { | | 
[ oc) | }———------{—-4 
1 0 | | D i | 
eee l-r-cc ce | +--> SEGMENT 2 
| E | | 
re a 
| * * *€ & *€ | 
| { 
| COMMON | 
| { 
Bete J 
Figure 20. Caller released from list 


Figure 20(a). A bank load from call local 


The load list (Figure 21) now has E at its 
top. E is in core. No new loading is 
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required. The segment level remains 2, but 
execution is now at level 3. E issues a 
CALL LOCAL, adding C to the pop-up list. 
Control passes to C (in core already at 
segment level 1). Execution is at level 4. 
Figure 21(a). 


Assume C RETURNS. 
which is reentered. 
E also RETURNS. 

which is reentered. 


It was called from E, 
Execution level = 3. 
It was called from D, 
Execution level = 2. 


D now issues a new CALL LOCAL, adding F to 


the pop-up list (Figure 21(b)). F is not 
in core, so it becomes segment level. 3. 
Core appears as in Figure 22. Control 
passes to F. Execution level = 3. 
== - ==4 "1 c— 
| E) | r--| A | [| F | 
| [ be age l | | 
1B | f | B | {iB | 
| Po fel ores ol l [ 
1c | ft § CC [<--y | c) | 
fo f | 1 | ,o | 
Loco t- | | | ae | 
r--| Df { 
2 ahaa | 
L_->| }---4 
1 Ef 
bee J 
Figure 21. No change to load list 
Figure 21(a). Module called is already in 
core 


Figure 21(b). CALL LOCAL transfers control 
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aS os | eaves | 
| { A | 

| SEGMENT 1 | l- - -] 

| { 1 B | 

f- —— <2 > 

| J} ¢ [-—-4 
| SEGMENT 2 | }-----4 | 
| { r--| D | { 
Se Eee 3 
| SEGMENT 3 | | cae | | 
{ | 1 | E |<--4 
| | [| _'---—-+4 
|----------- { >] F | 

| | t-——-—4 

| | | I 

| { { { 
|----------- { | | 

{ | | | 

{ COMMON { | | 

I | | | 
ee ene aa r) eae eee 

Figure 22. Control passes to a new segment 

Figure 22(a). Contents of segments 

Program F RETURNs. D is reentered. Execu- 

tion level = 2. D RETURNS to A. Execution 


level = 1. 


A issues CALL LOCAL, adding F to the pop-up 
list, F is in core, so it is entered. 
Execution level = 2. 

Execution 


F RETURNS. A receives control. 


level = 1. 


A issues a CALL LOCAL, adding H to the 
pop-up list. H is not in core. Control is 


in segment 1 and execution level is 1, so 
higher segments are released. Core now 
looks like Figure 23. Control goes to H. 


Execution level = 2. 


| A | 
[----I 
| BI 
|----| 
1 oc | 
}------—} 
| H | 
f-—------- 
| * * * *| 
| 

| COMMON | 
| ere 


Figure 23. 
segment 


New segment replaces released 


H issues a CALL LEX, adding E to the pop-up 
list. E is loaded and overlays H. (The 
reader should justify this statement.) E 
returns and A issues a CALL LOCAL without 
adding to the pop-up list. B will be 
entered in segment 1. B returns to A, 
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which again issues a CALL LOCAL with no 
change to the pop-up list. C will be 
entered. After a return from C, if the 
loader is entered again without adding to 
the pop-up list, the list will be empty. 


When loading from an empty pop-up, the PLAN 
module DFJPSCAN is’ loaded by default, to 
Obtain the user“s input. (A zero in the 
pop-up list appears to be the end of the 
list; so any program can return to _ the 
input reader by loading the name 0.) 


10.7.0 RETURN LINKAGE 


The FORTRAN RETURN statement functions 
exactly like the CALL LRET PLAN loader 
call. Register 14 is used to cause a 
return from the mainline (logic module) to 
the PLAN loader. PLAN modules that contain 
CALL LNRET or that are reentered ata 
primary entry may not exit via RETURN. 


FORTRAN subroutines which modify variables 


passed to them as arguments must use the 
FORTRAN RETURN statement. 


CALL EXIT should be used to terminate a 
module to assure that buffers have been 
purged and data sets closed when non-PLAN 
I/O is incorporated within a module. 


10.8.0 EXECUTION-TIME LINKAGE EDITING 


Because the PLAN loader has full control of 
the region Or partition, it can resolve 
references between load modules that were 
not link-edited together before execution. 


While loading a module, all unresolved 
ADCONS pointing to entries in in-core seg- 
ments will be resolved. 


External subroutine references that are not 
resolved at link-edit time are effectively 
treated as CALL LOCALS by the PLAN system 
at execution time. 


The restrictions on subroutines called in 
this manner are: 


a. Standard linkage conventions must be 
used 


b. Function subroutines may return ans- 
wers only in FPRO or GPRO 


The two sets of coding shown below are 
equivalent and correct. The V-con for 
SUBRTN in set 2 may be unresolved following 
link-editing. 
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SET1 
REAL*4 NAME(2)/'SUBRTN'/ 
e 
e 
e 
CALL LOCAL (2,NAME,ARG1,ARG2,ARG3) 
END 


SET2 
e 


° 
° 

CALL SUBRTN (ARG1, ARG2, ARG3) 
e 
e 
e 


END 


Unresolved branch type (v) ADCONS that are 
to be resolved by the PLAN load at execu- 
tion time are restricted. References to 
the ADCON must be direct. For example: 


L 15,=V (NAME) 
BALR 14,15 


Offset referencing as shown below will not 
function correctly and will probably cause 
termination of the PLAN JOB step. In other 
words, IBCOM= cannot be called as a LOCAL. 


L 15, =V (NAME) 
BAL 14,N(0,15) 


10.9.0 USE OF THE LINKPAC AND RAM AREAS 


A PLAN utility program (DFJLLIST), that 
gives the PLAN system the capability of 
referencing the LINKPAC or RAM area, is 
provided. This utility must be invoked by 
the PLAN command: 

CREATE LOADER ENTRIES: (NAME1, ...); 
where NAME1,... is a load module name that 
is to be loaded into the partition via the 
LOAD macro and be made available as entry 
points for the execution of any loader 
call. This allows programs in the LINKPAC 
or RAM areas to be objects of a CALL LOCAL. 
The names specified in the LIST must be in 
the JOBLIB PDS. To add this phrase to the 
dictionary, the following PLAN command must 
be executed: 

ADD PHRASE: PRO 
*DFJLLIST'; 


CREATE LOADER ENTRIES, 


The maximum number of names in the list is 
15. Use of this command destroys any 
entries defined by previous use of the 
command. 


Programs that reference blank COMMON may 
not be operands of this command. 
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10.10.0 USE OF IN-CORE DIRECTORY 


A PLAN utility program (DFJCRDIR) allows 
the user to build an in-core PDS directory 
of names of frequently loaded modules. 
This utility must be invoked by the PLAN 
command : 


CREATE CORE DIRECTORY: (NAME1,...-);3 
NAME1,... is a load module name that is 
placed in the in-core PDS directory to 
decrease load time for those modules. The 
names in the list must be entries in the 
PLANLIB PDS. 


Use of this command will replace the pre- 
vious directory. The maximum number of 
entries is 75 names. 


This facility is added to the PLAN language 
dictionary (PFILE) by executing the follow- 
ing command: 


ADD PHRASE: CREATE CORE DIRECTORY, 
PROGRAM ‘DFJCRDIR*‘; 


10.11.0 PARAMETER PASSING 


If the arguments in a parameter list are 
external names, the called program and 
calling program must be compiled by the 
same level FORTRAN compiler. 


10.12.0 OVERLAY STRUCTURE 


The System/360 OS PLAN System provides a 
local overlay structure that provides the 
mechanism for common usage of multiple 
purpose control sections. This type of 
processing is typified by an application in 
which the mainline serves only to provide 
linkage to logic segments that perform 
specific functions, and provides the basic 
hardware routines. 


The following logic module is considered 
appropriate for an application of the type 
listed above. It is assumed in the example 
that a command would initially load the 
example module and define the first local 
task to be completed by entries in the load 
list. 


EXTERNAL ARG1,ARG2,...ARGN 

1 CALL LOCAL(0,0,ARG1,ARG2,...,ARGN) 
GO TO 1 
END 


The local module would then be written in 
the following form: 
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SUBROUTINE NAME (ARG1, ARG2,...ARGN) 
CALL ARG1(X,Y,Z) 
CALL ARG2(P,Q,R) 


RETURN 


Return from the LOCAL immediately loads the 
next module indicated in the pop-up loader 
until the loader is found to be empty. At 
that time control is given to PSCAN for 
processing a new command. The logic module 
shown in the above example would incorpor- 
ate all multiple-use subroutines required 
by the local modules. 
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processing (EOF) before issuance of the 
call or must not allow the called module to 
use the file. It is not true of PLAN 
DYNAMIC, PERMANENT, and SEQUENTIAL file 
support. 


The use of CALL LOCAL in a source program 
suggests detailed knowledge of an installa- 
tion"s core storage boundaries. There must 
be room enough for all load modules that 
are implied by any sequence of CALL LOCALs 
without intervening RETURNS. Since core 
use is an installation variable, it is not 
good practice to use CALL LOCAL in general 
purpose modules. This call is designed for 
root modules containing shared subroutines 


Note that the module issuing the CALL LOCAL to use in invoking a hierarchical overlay 
or CALL LCHEX must complete non-PLAN file scheme. An example is shown below. 
1R Vv 
Sear na ee, 1 laa | pS 
| { { R | 
| 2 CALL LOCAL(0,0,A,B) | ; x | 
| GO TO 1 | | Zz] 
poo ------ +----> SUBROUTINE A | }Yy] 
| ote RETURN | } 0 | 
| | | r-> SUBROUTINE B | tJ 
| | | | RETURN] | INITIAL 
| | | | | { LOAD LIST 
| | | | | | 
| { t | | { 
| | | I | | 
I { S-S-— a a a saa 4 
| | \ | { 
{ | | I | 
| | { | | 
aap Pea ; Sepeormmaeat ses Se ama ara as 7 
1 | I i | { | 
1 | | { | | | 
2 x| | | 3 2| | | 4 ¥ | 
ta ot ocean === 1 
| Las hr, ts 1 | { ° { 
I l 1 | t toe i | | ° { 
| CALL A <j | { |CALL B < 4 1 | CALL LIST (2,A) | 
OVERLAY | : 1 1 : | i : | 
AREA | ° 1 | ° | | : I 
| CALL LRET | | CALL LRET | {| CALL LRET | 
beets J ee ee J Lee aie ae J 
Figure 24. OS overlay structure 
10.13.0 PLAN SYSTEM CHECKPOINT is found to be empty -- is destroyed. 


The following regulations govern execution 
and control of the checkpoint facility 
within the OS version of PLAN (CALL LCHEX): 


1. Checkpoints can be reloaded only within 
the limits of the phrase from which 
they were written. This means that any 
checkpoint that has not been reloaded 
when the end of the phrase is encoun- 
tered -- that is, when the pop-up list 


No warning message is issued. 


2. If the checkpoint return (*) is encoun- 
tered while in local mode, the local 
processing is terminated and the check- 
point is reloaded. 


3. Any input/output error 
writing the checkpoint 
in a phrase abort and 
recovery is initiated. 


while reading or 
data set results 
PLAN level error 
This action is 
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also true when insufficient space is 
availabie in the checkpoint data set. 


4. The user may specify, in the DCB BLOCK- 
SIZE parameter of the PLCHKPT DD card, 
the record size (in bytes) to be used 
when writing checkpoints. If no block- 
size is specified, a blocksize of 512 
is assumed. 


5. There is no logical restriction on the 


number or level of checkpoints that a 
user may execute. A physical limit 
based on the size of the checkpoint 


data set may produce a real limit or 
error condition as outlined in 2 above. 


6. Checkpoint restarts are executed in a 
reverse order from which they are writ- 
ten, that is, last in-first out. 


7. After a checkpoint is taken, the status 
of all data sets, except system data 
sets (those data sets processed by CALL 
PLINP, CALL PLOUT, CALL GDATA, and CALL 
FIND), must not be altered until the 
checkpoint is restarted. This isa 
user responsibility and no check is 
made by PLAN to prevent such an altera- 
tion. If a data set status is altered 
while a checkpoint is in effect, the 
results are unpredictable. 


8. COMMON is not protected between the 
time that a checkpoint is taken and the 
restart is loaded. It is the user 
responsibility to save and reload those 
parts of COMMON that might be destroyed 
and that must be present for continued 
execution of the checkpointed module. 


9. Floating-point 
restored when a 
restarted. 


registers are not 
checkpoint is 


10. The length of the PLAN PROGRAM/COMMON 
area must not be altered during the 
time a checkpoint is in effect. 


10.14.0 USER-EXIT PROGRAMMING 


The PSCAN user-exit program must be written 
to expect the standard System/360 FORTRAN 
subroutine linkage conventions. 


10.15.0 COMMUNICATION ARRAY SPECIFICATION 


The size of COMMON that is protected from 
overlay by PLAN system modules is’ the 
greater of (1) the size of PSCAN COMMON as 
defined at assembly time, or (2) the con- 
tents of Switch Word 9. PSCAN will give an 
error diagnostic and abort if an attempt is 
made to store values beyond these limits. 
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10.16.0 PERMANENT FILE SUPPORT 

The OS version of PLAN provides support for 
files established outside of PLAN with the 
following characteristics: 


1. File contains fixed length records. 


2. File may be organized as a 
or direct access file. 


sequential 


3. No secondary allocation is provided. 

4. Track overflow feature may not be used. 
5. No keys are allowed. 

6. There may be no control characters. 


7. The file may contain no truncated 
records. 


The logical drive number (NDR) and the 
logical file number (ID(1)) must be equiva- 
lenced to the data set name. The DDNAME 
“PLFSynnn" will establish a name/number 
equivalence between PLFSynnn and NDR/ID(1), 
where y corresponds to NDR and may range 
from 0-7, and nnn corresponds to ID(1) and 
may range from 1-255. 


10.17.0 DYNAMIC FILE SUPPORT (OS PLAN) 


The NALLO parameter provided with CALL FIND 
is used to optimize space allocation. The 
basic unit of allocation for an OS PLAN 
file is 1350 words. 


The positions of the NDR parameter other 
than the units position are not interro- 
gated by OS PLAN. Each logical file can 
contain up to 147 discontiguous alloca- 
tions. Thus, if normal allocation is 
allowed as the file is written, the maximum 
file size is restricted to 220,500 32-bit 
words. If the NALLO parameter of the CALL 
FIND subroutine is utilized, the maximum 
file size is 49,150,350 32-bit words. 


Each logical drive may contain a maximum of 
149 discontiguous free areas. This means 
that in cases of extreme discontiguous 
allocation a file may be destroyed. 


10.18.0 IOCS DEVICE PARAMETERS 


Under System/360 OS PLAN, INPUT and LIST 
correspond to units defined as DD names 
defined in the JCL for the PLAN job. The 
value specified for INPUT or LIST, corre-~- 
sponds to the device specified as the PLAN 
input device PLINPnnn in the job descrip- 
tion deck. Unit nnn specified for LIST, 
corresponds to the device specified as the 
PLAN output device PLOUTnnn. 
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10.19.90 SEQUENTIAL FILE SUPPORT 


The following steps outline the manner in 


which certain special conditions are 
handled on the 0S/360 version of the 
SEQUENTIAL I/O subroutines. (PLINP/PLOUT/ 


PEOF/PCCTL). 


Two subroutines are provided under OS PLAN 
that allow specification of page length and 
status switching (CLOSE) for PLINP/PLOUT 
data sets. 


CALL PPAGL(NOD,N) is a subroutine used to 
specify the number of lines to be used as 
the page length for those data sets con- 
taining printed output. If N is 0, a 
default of 60 is used. The maximum value 
of N is 32,767. 


A call to PPAGL sets the current line count 
to the page length specified. It also 
forces the next carriage control operation 
to be a skip to 1 unless overridden by an 
intervening call to PCCTL. 


CALL PENDF(NOD) is a subroutine that may be 


used to close a sequential data set. If a 
data set is in output status, an EOF is 
written after the last record. Both PLINP 


and PLOUT data sets are repositioned to the 
beginning of this data set. 


1. Maximum record size for any input/ 
output record is 32,760 characters. 


2. Records may be blocked within the 
limits of the facility for processing 
on the specified device. Truncated 
records are accepted if the character 
count is a multiple of the logical 
record length. 


3. A PLINP/PLOUT call to an invalid device 
(missing DD card) is ignored. 


4. In order to effect carriage control, 
that is, for PCCTL to be functional, 
the DCB RECFM parameter must be FA or 
FBA,. 


5. The DCB RECFM parameter must be F, FA, 
FB, Or FBA. 


6. If the device is a printer, the DCB 


RECFM parameter must be FA. 


following 


7. The items define PCCTL 
functions: 

a. If the device is a reader, PCCTL 

will control stacker selection. 


DCB=(RECFM=F, BUFNO=1) must be used. 
b. If the device is a punch, RECFM must 
be FA for PCCTL to control stacker 
selection. 
c. If RECFM is 
cause the 


FA or FBA, PCCTL will 
correct ASA control 
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character to be inserted asthe 
first character of the record. 


8. The following items are 
for the PEOF routine: 


specifications 


ae (1) Logical EOF is set when a 
"UREND" is read by CALL PLINP. 
The logical EOF will be reset by 
the next CALL PLINP to the data 
set. 
(2) The line count is zero for out- 
put data sets (CALL PLOUT) using 
RECFM FA or FBA. 
b. Physical EOF is set when: 
(1) EOF is read by a CALL PLINP. 
(2) A call PLINP is issued toa 
device not capable of input. 
(3) A CALL PLOUT is issued to a 
device not capable of output. 
(4) A CALL PLOUT is issued to a data 


set in input status (a CALL 
PLINP had previously been 
issued). 


(5) A CALL PLINP is issued to a data 
set in output status (a CALL 
PLOUT had previously been 
issued). 


9. The following specifications pertain to 
the carriage tape simulation functions 
on an output device (CALL PCCTL): 


a. The maximum page length is 
lines. 

b. Default page length is 60 lines. 

c. If RECFM is FA or FBA, a line count 
is maintained and an automatic eject 
(skip to carriage channel 1) is’ set 
when the line count reaches zero. 

d. Maintenance of the line count is 
suspended when a PCCTL CALL is 
issued for a skip to channels 2-12. 

e. Maintenance of the line count is 
resumed when a CALL PCCTL is issued 
for a skip to channel 1. 


32,767 


A PLAN utility program (DFJPLENG) allows 
the user to set the page length to be used 
on an output file that is to contain data 
to be printed. This utility must be 
invoked by the standard PLAN command. 


SET PAGE LENGTH, NOD xxx, PGL yyyyy; 


where xxx is a number up to three digits 
equivalent to the NOD argument’ for the 
subroutines PLINP and PLOUT and yyyyy is a 
number up to five digits to be used as the 
page length for the specified NOD. 


10,20.0 PROGRAMMING RESTRICTIONS 


The following System/360 FORTRAN statement 
should not be used because of its detri- 
mental effect on the execution of PLAN. 
Alternate facilities are listed for each 
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option. To avoid overriding the PLAN pro- 
cessor or endangering another user's job, 
the statement should not be executed. 

CALL DUMP This statement creates a pre- 
mature end to the PLAN execu- 
tion. Therefore, the CALL 
PDUMP, followed by a CALL 
LRET, should be used. 
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10.21.0 PERMANENT FILE SORT/MERGE 


CALL GSORT(ID) and CALL GMERG(ID,JD,KD) 
provide the identical function for PER- 
MANENT files as provided by CALL PSORT and 
CALL PMERG do for DYNAMIC files. 
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11.0.0 APPENDIX D: 


This appendix shows the optional and 
required elements of a PLAN statement. The 
first section shows the requirements for 
language definition and the second section 
shows the syntax of language use. Capita- 
lized entries, left parenthesis, and right 
parenthesis are standard (nonvariable) 
items. Lowercase entries are replaced with 
variable information. Items in brackets 
are optional items. This material is pre- 
sented in outline form to allow successive- 
ly more detailed presentations of various 
items and options. Items enclosed in 
braces may be entered more than once. 


Figure 25 is a graphic representation of 
the syntactical organization of the PLAN 
language. 


11.1.0 LANGUAGE DEFINITION SYNTAX 


I. ADD PHR: namel(,definition]; 
A. name is one to five words 
B. definition 
1. (LEVEL n,] 
2. (PROGRAM‘ program list’, ] 
3. ([VERB{*program list'],] 
4. (EXIT ‘program list',] 
5. (data definition, ] 


The following abbreviations are used in the 
syntactical entries: 


aex = arithmetic expression 

aop = arithmetic operand 

cap = communication array position 

chk = check entry definition 

dan = data name 

dav = execution-defined data value (numer- 
ic, logical, literal) 

I = mode (I=integer) 

lex = logical expression 

lop = logical operand 

nuv = numeric value 

prl = program list 

Ptn = scale factor 

saop= special arithmetic operand 

sdv = standard data value (numeric, 
logical) 

slv = standard literal value 

Um = user exit 

- = arithmetic operator 

$n = formula number 

® = logical operator 

t = relational operator 

{(cap)sdv, ] 

((cap) dan, ] 
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SYNTAX OF THE PLAN LANGUAGE 


((cap)dan sdv,] 


{I (cap) dan, ] 

(I(cap) sdv,] 
(I(cap)dan sdv,] 
(Ptn(cap)sdv,] 
(Ptn(cap)dan,] 
{Ptn(cap)dan sdv,] 
{I Ptn(cap)sdv,] 

{I Ptn(cap)dan,] 

(I Ptn(cap)dan sdv,] 
{Um(cap) dan, } 
[Um(cap)dan sdv,] 
{Um I(cap)dan,] 

(Um I(cap)dan sdv,] 
(Um Ptn(cap) dan, ] 
{Um Ptn(cap)dan sdv,] 
{Um I Ptn (cap) ,] 

{Um I Ptn(cap)dan sdv,] 
{ (aex)dan,] 

{ (aex)dan sdv,] 

{I (aex) dan, ] 

({I(aex) dan sdv,] 

[ Ptn(aex)dan,] 

{ Ptn(aex)dan sdv,] 
{ I Ptn(aex) dan, ] 

{I Ptn(aex)dan sdv,] 
{Um (aex) dan, ] 
{Um(aex) dan sdv,] 
(Um I (aex) dan, ] 

{Um I(aex)dan sdv,] 


{Um Ptn(aex) dan,] 
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{Um Ptn(aex)dan sdv,] 
{Um I Pt+tn(aex)dan, ] 
(Um I Ptn(aex)dan sdv,] 


{UM] (11 (Ptn] (cap) (dan) [sdv] 
(f{lex}] ({aex}] 


{slv] (fchk}] 


The following entries show valid syntacti- 
cal entries for the phrase-defined formula 


area. Abbreviations used are defined 
above. Note that none of the preceding ADD 
PHRASE entries may follow any of the 


entries below. 


[$n] ({dan]=aex, 


{$n] [dan]: lex, 

{$n] [dan]: (lex) [?=aex], 
[$n] [dan]: (lex)[?:lex], 

{$n] (tdan]: (lex) [?$n], 

{Sn} [dan]: (lex) [?=aex!=aex], 
{$n} ({dan]: (lex) [?:lex!:lexl], 
{$n] (€dan]: (lex) (?=aex!:lexl], 
{$n} (dan]: (lex) (?:lex!=aex], 
[$n] [dan]: (lex) [?$n!=aex], 
{$n] (dani: (lex) (?$n!:lex], 
{[$n] (dan]: (lex) (?=aex!Sml, 
{$n] [dan]: (lex) (?:lex!$ml, 
{$n]:$n, 


The following entry is the valid form for 
arithmetic operands: 


dan {<+dan} {<«nuv} 


The following entries are valid forms for 
special arithmetic operands: 


+ 
"LITERAL" 
*LITERAL' 
aLITERALa 


The following entries are the valid forms 
for arithmetic expressions (aex) in phrase 
entries. Braces define the acceptability 
of multiple entry of the enclosed items. 
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=aop {<aop} 

=saop 

The following entries are valid forms for 
logical operands (lop) in phrase entries 
(execution or ADD PHRASE): 

dan f{edan} 

(aextaex) 

(dan="slv") 

(dan=+) 

(dan=-) 


Logical expressions (lex) may be written in 
the following valid form: 


lopfelop} [?:lopfelop}] 

lop felop}[?:lop{elop}!:lop{elop},] 
lop{elop} [ ?=aex] 
lop{felop} [?: lop{elop} !=aex] 
lopf{elop} (?=aex!:lop{elop}] 


Note that there are other combinations of 
the elements shown above. In addition, 
parentheses may be used within logicals to 
show order of evaluation. 


11.2.0 LANGUAGE USE SYNTAX 


General format of execution-time PLAN 


statements is shown below: 


I. Command, data section; 
, data section: 
Command; 


A. Command 
phrase 
{verb phrase}® phrase 


B. data section 
{ Jdav( 1(,] 
{ Idan( J(,] 
{ Jdan{ Idavl l1{[,] 
[$n] € Jdan(€ J={€ Jaex[( ] 
{Sn} (€ ) danf J:{€ Jlex({ J 
[$n] (€ J=(€ Jaex[ ] 
{$n} € ] :€ Jlex( J 
{ } dan€ ] (aex) £ ] (,] 


[Sn] (€ ] danl ] (aex)C Jdav (€ ] [(,] 
{Sn} (€ ] {$ ] danl ]J(aex) [ ]={ ] 
aex[ ] 

{$n} [ ] dant ] (aex)( J:f{ ] lex [ ] 


C,] 


15 SEPTEMBER 1969 


Figure 25. 


STATEMENT 
| 
| 
(mono a a a 
COMMAND e 
{ 
esl ceos meses —1—----~---~} 
VERB OBJECT 
| (MAX 8) | (MAX 1) 
i 1 
PHRASES... « PHRASES... 
| 
| 
r-—-~4+---~-4 
WORD1... WORDS 
| 
abe 
ALPHA ¢ BETA... | 
3 | 3 
BLANK | 
if jj 
CONSTANTS LITERALS 
| | 
| *LIT* 
p----1-+-—- "LIT" 
REAL LOGICAL aLIta 
INTEGER TRUE 
FLT. PT. FALSE 
corre 
OPERANDS 


PLAN execution-time statement syntax 
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DATA H 
| 
t-—4 
| 
| 
 neneeneintenene 1 
NAMES VALUES 
| | 
| | 
I | 
WORDS | 
| 
| 
| 
| 
| 
| 
| 
eet ee eoaned 
| 
FORMULAS 
| 
| 
tS 1 
ARITHMITIC LOGICAL 


EXPRESSIONS EXPRESSIONS 


| { 
| | 


~-——1——1 p~t~---—~--- 4 
OPERATORS OPERANDS OPERATORS 
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12.0.0 APPENDIX E: 


12.1.0 PFILE LAYOUT 


The PLAN language definition file (PFILE) 
is generated and maintained by the PHRAS 
logic module and is utilized by PLAN (load- 
er) and PSCAN for temporary system save 


PLAN SYSTEM FILES LAYOUT 
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PFILE is defined as a logical file contain- 
ing a minimum of 14 (17 on the 1130) and a 
maximum of 268 (205 on the 1130) records. 
Records in PFILE are fixed in length at 512 
bytes on System/360. On the 1130 each 
record is 320 (16-bit) words in length. 


areas. PFILE is required to be present The following table lists the contents of 
before a PLAN execution is permitted. PFILE. 

Le ee ee ae ee wea eS a ee ee 1 
eee SIZE IN RECORD 
| NAME RECORDS DISPLACEMENT DESCRIPTION | 
LpEpRSY 5 0 Loader save and error stack area 
iseears 1 5 Level 4 symbol table save area (128 words) 
ieEraEUre 1 6 Card image residual save area (20 words) 
opeees 1 7 Level 3 symbol table save area (128 words) 
ee 1 8 Phrase-verb validity table (512 bytes) 
| PPsver? 1 9 Level 2 symbol table save area (128 words) | 
| OFINPUTA 1 10 Current statement image save area (114 words) 
ipRener 1 11 Level 1 symbol table save area (128 words) 
ierekers 1 12 Phrase entry availability table (512 bytes) | 
ieEvenay * PSCAN save area | 
ipreeine 1-255 13 or 16 Phrase entry table 
*NOTE: This area is used in 1130 PLAN for saving portions of the PSCAN module. It | 


} consists of 3 sectors on the 1130 but is not present under OS or DOS PLAN. 


Ucn se ce ee cs cee ne mee a stn nce A Ec A i SO Ae SE SSS SU RS a A SE A N.Y SE AS RS SD Se SES SE aR ENN GOED eA SEED SED ND SS a SN EN AES OS IS AT en | 


The following section describes the func- 
tions of each of the areas listed in the 
above table of contents: 


PFLDRSV This area is used for temporary 


storage of the 1130 PLAN loader. 
The use of this area is initiated 
by: 

1. CALL LSAV 

2. CALL PSORT 

3. CALL PMERG 

On all PLAN systems the area is 


used as a temporary stack area 
for diagnostics awaiting proces- 
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sing by the system error module 
when a stacked mode of operation 
is indicated. 


PFSYMT4 This area is used to store the 
level 4 symbol table. The symbol 
table must be saved for use in 
initializing the symbol table of 
a blank-level command following a 
level 4 command. 

PFINPUTB The image of the card, to the 


right of the semicolon terminat- 
ing a command, is saved in this 
area for processing as the start 
of the following command. (Hexa- 
decimal 00 indicates the end of 
the image.) 
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PFSYMT3 


PFPWVTAB 


PFSYMT2 


PFINPUTA 


PFSYMT1 


PFPAVTB 


PFPETAB 


This area is used to store the 
level 3 symbol table. The symbol 
table must be saved for use in 
initializing the symbol table of 
a blank-level command following a 
level 3 command or _ the symbol 
table for a level 4 command fol- 
lowing this level 3 command 
without intervening commands of 
level 3 or higher. 


This table is used as an expe- 
dient to determining phrase 
validity. There are 256 entries 
corresponding to the 256 possible 
phrase check sums. A zero entry 
indicates no valid phrase has the 


check sum; a nonzero entry is a 
pointer to the phrase entry 
table. 

This area is used to store the 


level 2 symbol table for use in 


initializing the symbol table of 


a blank-level command following a 
level 2 command or the _ symbol 
table of a level 3 command fol- 
lowing this level 2 command 
without an intervening command of 
level 2 or level 1. 


used to store the 
EBCDIC image of 
PSCAN places 


This area is 
length and the 
the current phrase. 
the command in this area for 
access by PHRAS. The subroutine 
INPUT reads the statement image 
from this area and places it in 
memory. 


This area is used to store the 
level 1 symbol table for use in 
initializing the symbol table for 
a blank-level command following 
this level 1 command or the sym- 
bol table for a level 2 command 
following this level 1 command 
without an intervening level 1 
command. 


table 
in the phrase 


There is one entry in this 
for each record 
entry table. The entry provides 
information as to the available 
room within each record for the 
addition of new phrase 
definitions. 


This portion of the PFILE con- 
tains the language description 
elements. Each command is 
entered with header information 
followed by up to seven tables of 
phrase definition data. The 
length of this section is vari- 
able up to a maximum of 255 
records, a function of the number 
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of commands that must be added 
into the language dictionary. 


The following section describes the detail 
layout of the variable (maintained) por- 


tions of PFILE. Those portions that are 
merely temporary storage areas are not 
described. 

12.1.1 PFPWVTAB (PHRASE-VERB VALIDITY 
TABLE) 

This section has 256 entries corresponding 
to the 256 possible phrase check sums. The 


word check sum of each word in the phrase 
is calculated as: 


KSUM = L1*4 + L2*2 + L3 


L1 First letter in EBCDIC in low- 
order eight bits 

L2 = Second letter in EBCDIC in low- 
order eight bits 

L3 = Third letter in EBCDIC in low- 
order eight bits 

Only the low-order eight bits of the word 


check sum are saved. The phrase check sum 
is formed by the “exclusive or" of succeed- 
ing word check sums. The following example 
illustrates the calculation of the phrase 
check sum for the phrase "DUMP PLAN": 


Word Check Sum Calculations 


D 11 0001 0000 310 
U 01 1100 1000 1c8 
M 00 1101 0100 OD4 
101 1010 1100 5AC AC 
P 11 0101 1100 35c 
L 01 1010 0110 1A6 
A 00 1100 0001 0c1 
101 1100 0011 5c3 c3 
DUM 1010 1100 AC 
PLA 1100 0011 c3 
0110 1111 6F 
The 256 entries accessed by the phrase 
check sum have the following format. Each 
entry contains 16 bits. The term "“record/ 


64" in the following discussions means 64 
bits on System/360 and 80 bits on the 1130 
System. This grouping is one sixty-fourth 
of a disk record. 


| | | | 
Contents |V]| A | B | 
Pia ee eee ee en eee 4 
Bit 012 7 8 15 
V verb Control 
0 if no verb phrase has this check sum 
1 if a verb phrase has this check sum 
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A The number of records/64 from the 
beginning of the sector indicated by B 
to the first phrase entry in the chain. 


B Those bits contain the relative sector 
address (1-255) of the first phrase 
entry in the chain of phrases with 
equal check sums. The field is zero if 
no valid phrase has this check sum. 


12.1.2 PSYMT 1,2,3,4 (SYMBOL TABLES) 


This section is made up of 255 bytes of 
information, including 126 (16-bit) words 
containing the symbol table entries. The 
format of the table is shown in the follow- 
ing chart: 

i | | 


Contents |O[R{IL]0] E | 
EY HR SOR) eee eee ere as 
Byte 01234 255 


R The relative byte (8-bit) address of 
the first table entry. The tables are 


built from left to right. The right- 
most entry wraps around to the left 
end. The last (rightmost) value 


entered is 
zero entry. 


preceded to the right by a 


L The level of the symbol table is indi- 
cated as the level minus one. Thus, 
the indicator occupies the second and 


third bits and ranges from 0-3. 


E Each symbol is 
form from the phrase. 
initialized from the symbol table of 
the next higher level. The format of 
the compressed symbol is shown in the 
chart below. The symbol allows expedi- 
tious detection of undefined symbols. 
Note that the symbol table entry is the 
same as 1 and 2 of Table 3. 


entered in compressed 
The table is 


| | | | | 
Contents |Letter 1|Letter 2|Letter 3/0 | 
L Pa Sepa eo a eee od eee eens cee 


Bit 0 4 5 9 10 


The letters 
bits through 
compression: 


compressed into five 
the following code 


are 


LETTER COMPRESSED CODE 
A-I 1-9 

J-R 11-19 

S~Z 22-29 

blank 0 


12.1.3 PFPAVTB (PHRASE AVAILABILITY TABLE) 
This section of PFILE contains a maximum of 


256 entries corresponding to the number of 
records in PFPETAB. Each entry is a half- 
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word (16 bits). The entry format is shown 
in the following table: 


B The number of records/64 to the begin- 
ning of the first phrase entry or 
available space entry in the _ sector. 
The value of 7FFF (hexadecimal) indi- 
cates that the entire sector is avail- 
able; 8000 (hexadecimal) indicates the 
end of the table. 


L The number of records/64 in the largest 
contiguous, available block that begins 
in this sector. This entry is used as 
a test for the possible addition of the 
current phrase into this sector. 


12.1.4 PFPETAB (PHRASE ENTRY TABLE) 
The available space entries and the phrase 


entries in the phrase entry table are 
packed across sector boundaries. The first 


records/64 of the phrase entry table must 
be initialized when PLAN is invoked. If it 
is not, the ADD PHRASE command is set and 


PHRAS is loaded to add it to PFILE. The 
format of the PFILE header is shown below 
in hexadecimal. 


| | | 

P | 
{0001] D7 | 
en Seen i 
0-15 16-23 24-31 32-39 40-47 48-55 56-63 


Note that bits 16 to 63 contain the EBCDIC 
representation of PFILE. On the 1130 Sys- 
tem, bits 64-79 are included but unused. 


The first word (32 bits) of each phrase (or 
available space) entry provides data as to 
the size of the entry and pointers to the 
next item in the chain. The format of this 
portion of the entry is provided below: 


i | lft ol i | { { 
|T] L |xfooo] s | vi z | SA | 
a ee i ee ne ee es Te | 
0134578151617 23 24 31 


7 This bit determines whether this is a 
phrase entry or an available-space 
entry. 


0 = Phrase entry 

1 = Available space (The following 
fields, except S, are meaningless 
if this is an available-space 
entry.) 


L These bits (in a phrase entry) define 
the level of the phrase according to 
the following table: 
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000 Level 1 

001 Level 2 

010 Level 3 

011 Level 4 

100 Blank level 
x The presence of this bit indicates a 
level zero phrase. 


Ss These eight bits define the number 
(<128) of records/64 in this entry. No 
phrase may result in an entry of great- 
er than 128 records/64. The appropri- 
ate diagnostic is issued if such an 
attempt is made. 


Vv This bit (in a phrase 
whether the phrase is 
object phrase. 

0 = Object phrase 
1 = Verb phrase 

Z This six-bit (<64) field defines the 
number of records/64 (within the sec- 
tor) that precede the first word of the 
chained-to (phrase with equal check 
sums) entry. This entry and the fol- 
lowing entry allow direct access of the 
chained phrase. 


entry) defines 
a verb or an 


SA This eight-bit field (<256) defines the 
sector address, relative to the first 
record of the phrase entry table minus 
one word, of the first word of the next 
chained-to phrase. This field is zero 
if this phrase is the last of a chain. 


Note that all phrases of equal check sum 
(as defined under phrase-verb validity 


table) make up the links of the phrase 
chain. 
Following the phrase entry header, as 


defined above, are up to eight tables. 
Each table is ended with 80xx (hexadecim- 
al), where xx is the number of 16-bit 
half-words in the following table. The 
last table is terminated with 7FFF (hexade- 
cimal). Trailing tables of zero length are 
not required, nor is the table length 
indication (8000) entered. 


12.1.5 TABLE 1 (PHRASE NAME) 


One word (32 bits) is required for each 
word in the phrase name. There is a 
Maximum of five double-words used. Letters 
are coded in EBCDIC code. 


{ | { | [ 
{Letter 1|[Letter 2]|Letter 3] (Not Used) | 
tL 1 1 J 


0 7 8 15 16 23 24 31 
Note that the next table (80xx) or last 
table (7FFF) indicator is placed in the 


next half-word. 
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12.1.6 TABLE 2 (CONSTANT INITIALIZATION 
DATA VALUES) 


This table contains all constant (default 
or initialization) values. There are four 
formats for this entry that depend upon the 
format of the phrase definition. In the 
following table definitions, the example 
phrase entry is given, followed in order by 
the general form of the table entry, the 
description of the table, and the table 
entry representing the example phrase 
entry. Note that there is. one entry 
required for each literal character count 
plus one for each succeeding group of four 
literal characters. 


1. Constant Value: 1(35)10, 


Iti | 

Oyo, S | vi | 

i Jj 

01215 16 47 
S This 14-bit (<16,384) field defines the 


subscript relative to the beginning of 
the switch area. 


V This 32-bit field defines the initiali- 
zation value as defined in the phrase 
entry. 


Plidet@ &€ t— t ft — Edt 
[OJO{2{D JO JO {O {O JO fO {Oo [A | 
| es SS ee Sn Cos So Sete 
0 4 8 12 16 20 24 28 32 36 40 44 


2. Symbolic Subscript: I(M)DATA3, 
| | i | | 
41 ¢c {| OF S fF V I 
Hee) Ceneeeaeloeeeis Seay! NUS mememeeNe a fame en ee J 
01 15 16 17 31 32 63 
Cc This 15-bit field contains the com- 
pressed data name in symbol table code 
that is to be initialized. The symbol 


is stored in the same compressed code 
as defined for the symbol table 
entries. 


S This 15-bit field contains the _ sub- 


script relative to the data name into 
which the initialization value is 
stored. 


V This 32-bit field defines the initiali- 
zation value as defined in the phrase 
entry. 


(itt { | 
19{0{3{ 7[ 0002 {| 00000003 | 
, el Eee) Es EC eer ie ce a er a a ces J 
04 8 12 16 28 32 63 


3. Implied DO: 1(30,36,2)15,... 
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oat S | DBD | FTF |v { 
1.1L... nn Ty 1.4 
012 1516 3132 47 48 79 


S This 14-bit (<16,384) field contains 
the subscript associated with the data 
value relative to the beginning of the 
Switch area. 


D This 16-bit field contains the 
displacement (range) for the implied 
DO. The value must be a multiple of 


field I. This value is computed from 
the first two specified implied Do 
parameters. 


I This 16-bit field contains the incre- 


ment for the implied DO. 


V This 32-bit field contains the initial- 
ization value as defined in the phrase 


entry. 
Lt it 
[4jOj,2qs8 | 0006 {0002 |OO000000F| 
EES Uamlon leet (eseeany! Ioan enerrenen occ earn Xt eae ear i i ie sli 4 
04 8 12 16 31 32 47 48 719 


4. Symbolic Subscript and Implied DO: 
(M+2,10,2)NAME1,... 


i 1 | | | 
lacs [ 14f D | I | 
Ls ane Mee Ree See! Come etna 2. dj 
01 151617 31 32 47 48 79 


CS This field contains the compressed data 
name of the starting position to be 
initialized. The symbol is’ stored in 
the same compressed code as defined for 
symbol table entries. 


V This 32-bit field contains the initial- 
ization value defined in the phrase 
entry. 


D This 16-bit (<65,536) field contains 
the displacement from the first posi- 
tion to be initialized to the final 
position to be initialized. 


I This 16-bit field contains the incre- 
ment between succeeding values to be 
initialized. 


1 | | | | I 
{B| C2E] 800A] 0002 | 00000001 | 


a a Seeres Sane 1 - ae 
0 16 32 48 719 


12.1.7 TABLE 3 (SYMBOL TABLE) 


1. Symbol 
Scale Value: 


with Constant Subscript and 
P+2(15) ABC... 


142 FILE LAYOUT (12.0.0) 


15 SEPTEMBER ‘1969 


{ I | | | i | | 
1S {Of E { I] P {| Gl SUB | 
L—._..41 —L_...—-—L— 

0 14 15 16-17 18 19-21 22 23 31 


1 —- LL. — 1 


Ss This 15-bit field contains the com- 
pressed data name to be defined. The 
format is as defined above for symbol 
tables. 


E This field defines the user-exit number 
to be associated with this symbol. 


00 = No exit 
01 = User exit 1 
10 = User exit 2 
11 = User exit 3 
I This field defines the mode for the 
variable. 


0 = Real (floating-point) 
1 = Integer (fixed-point) 


P This three-bit (<8) field contains the 
scale factor to be associated with this 
symbol. 


G This one-bit field determines the sign 
of the scale factor. 
0 = Positive 

1 = Negative 


SUB This nine-bit (<512) field contains the 
subscript of the value to be entered in 
the symbol table relative to the first 
position of the communication array. 


Pttdet ft tl | 
JO(8]8} Gf Of 8] Of F | 
t..L—1...£.....b—..L. 1. LJ 
0 4 8 12 16 20 24 28 31 


2. Symbol with Constant Subscript and No 


P-value: IU2 (25)VALUE... 
| | i | 
i s i 1 E { I | SUB | 
( nee ae a Eee eee Ewen et eee Nena Se ene J 
0 14 15 16 17 18 19 31 


s This 15-bit field contains the com- 
pressed data name in the mode indicated 
for symbol table entries. 


two-bit field defines the user- 
this 


E This 
exit number to be associated with 
data name. 


I This one-bit field determines the mode 
of storage. 
0 = Real (floating-point) 

1 = Integer (fixed-point) 


SUB This 13-bit (<8192) field contains the 
subscript associated with the data name 
relative to the switch area. 
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Pidt tt | | 
jc(8p5] BY Al OF 4p 9 | 
t..L1. be 4 
058121620 24 28 31 


3. Symbols with 
(M+ 2-N) ABC. ee 


Symbolic Subscript: 


The symbolic subscript is indicated by 
setting SUB to zero. The subscript defin- 
ing expression is then appended to the 
symbol table entry in EBCDIC code with a 
prefixed left parenthesis and a terminating 
comma. 


I | | 
| 08860000 | 4DD4S4EF260D56B_ | 


12.1.8 TABLE 4 (PROGRAM LIST) 


The program list table is made up of one 
entry per program in the list. 


1. Program Name: M0798,... 


| | 
| 8-CHARACTER EBCDIC NAME | 
| (RIGHT-PADDED WITH BLANKS) | 


Pr tri rit ti ttt tri retl 
at i Ra a Od a a ad 

Lt Lobb LL bi LL 
o ae 17 31 32 60 


2. Checkpoint Return (asterisk) 


| | 
| Sc4O404040H04040 | 
Wa ets es apne | 


0 64 


3. Left Parenthesis (EBCDIC) 


{ | 
| SD4O4O4040H04040 | 


4. Right Parenthesis (EBCDIC) 


{ i 
| SD40O404040404040 | 


12.1.9 TABLE 5 (DATA CHECK ENTRIES) 


1. Test, Abort, Generate PLAN Literal: 


(5) *, 008 
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| | 
{0} * | SUB {| cm | 
LiLo Le Sn J 
0123 15 16 31 


* This two-bit field contains the condi- 


tion code. 


00 = * 
01 = *R 
10 = ¥*T 
11 = ¥*F 
SUB This 13-bit (<8192) field contains the 


subscript relative to the switch area 
of the PLAN word to be tested. 


CTL If this field is nonzero, there is a 
suffix section, as defined under 4 and 
5, starting at field "F". 


2. Test, Abort, 
Symbolic Subscript: 


Generate PLAN Literal; 
(M) NAMEFR, @ee 


jo] * -0- | O| SYM CTL | 
01 2 3 15 16 17 31 32 47 

* (See above) 

SYM This 15-bit field contains the com- 


pressed data name in the format as 
defined for symbol tables. 


CTL (See above) 


| | | r tt ¢ tt 

1 21 Of OF OF FTCI2TEI 

tL 1... 1... 41. 4-1-1 J 
0 4 8 12 16 20 24 28 


3. Same conditions as above: 
Same as previous example, plus: ,*F 


jo] * | -O- | 1] SYM | sUB | cTL | 
LL. LL. -bL  LLd 
0123 151617 3132 4748 ~ 63 


* (See above) 
SYM (See above) 
CTL (See above) 
SUB This 15-bit (<32,768) field contains 


the subscript relative to the data name 
that is to be checked. 
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fiir @ t t t t t t 1 
}6]OJO] OF BY C] 2] El Of Of OF 2] 
| ee ee Ce ee ee Cee ieee Sees een eens (eee WED | 
0 4 8 12 16 20 24 28 32 36 4O 44 


Note: In the following examples the for- 
mats defined in 1, 2, or 3 above remain the 
same as a function of conditions except for 
bit 0 and the last 15-bit field. Bit 0 
will indicate whether the literal to be 
processed is implicit (1) or explicit (0). 
The last 15-bit field will contain function 
information for the literal processing. 


4%. Process Implicit Literal: ( )#*T2Z(9) 


Note: Z in the above example is a user- 
given function code and will be reflected 
in the F field below according to the 
following table. 


If Z= A (Abort) then F = 00 
=c (continue) = 01 
= P (Phrase) = 11 
=b (List) = 10 


| | | 
|1| SAME AS 1, 2 oR 3 | F [ SUB | 
Ho en nt re ee es a ee bee | 


01 
F See above table. 


SUB This 14-bit (<16,384) field contains 
the subscript relative to the start of 


the communication array that contains 
the literal to be processed. 
5. Process Explicit Literal: 
( )*TZ'LITERAL' 
I | 
jO] SAME AS 1, 2OR3 [|FI[L | Q | 
ar CR te See epee eee Re ees eee 
01 noi 15 16 n 
F Same as example 4. 
L This 14-bit field contains the length 


of the literal in 16-bit words. 


Q This variable-length field contains the 
literal in EBCDIC packed format. 


12.1.10 TABLE 6 (PHRASE-DEFINED 
EXPRESSIONS) 


This table is made up of two sections. The 
following three examples define the format 
of the possible first-section entries: 

Factor: P+3 (7) 


1. Value with Scale 


A=A*¥.017453... 
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G S | T | 
0 12 3 567 15 16 n 
I This field designates the storage mode 


of the data value. 
0 = Real (floating-point) 
1 = Integer (fixed-point) 


P This three-bit (<8) field designates 
the scale factor to be applied to the 
result of the expression before 
storage. 


G This bit designates the 
scale factor. 
0 Positive 
1 Negative 


Sign of the 


S This nine-bit (<512) field contains the 
subscript associated with the data 
value relative to the first position of 
the communication array. 


T This variable-length field contains the 
text of the phrase-defined expression 
terminated with a comma. The text is 
compressed to eliminate meaningless 
blanks and characters. ; 


ieee Nea | | [ | | | 1 | 

{8c{O7]| Ci] 7E{ C1] 5c] 4B] FO] Fi... | 

| oe i ee ee es a nn s\n | 
0 8 16 24 32 40 48 56 64 


2. Values without Scale Factors: I (12) 
I=1I*¥12... 

| | | { 

{ 11 [1] S I T | 

Rs ys 2 2s x Seana ete eee J 

0 123 15 16 n 


I See above. 


Ss This 13-bit (<8,192) field contains the 
subscript of the data value relative to 
the start of the systems switch area. 


T See above. 

| | | | | [ I | { | 
| EO] 16] 7E| C9] VE] C9] 5C] F1] F2| 
Be I ey 
0 8 16 24 32 40 48 56 64 


3. Value with Symbolic Subscript: (m+5) 
A, : (B>0) 
| i I 
{ 00 | S | O| Cc | T | 
[ ence nel en eneanemnee x aed Parenter nes isi atts J 
012 15 16 17 31 32 n 
Ss This 14-bit (<16,384) field contains 


the subscript relative to the data name 
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into which the result of the expression 
evaluation is stored. 


Cc This 15-bit field contains the com 
pressed data name in the symbol table 
code. 


T See above. 


1 t 4 { | | | { | | | 

{00]02] O4f OO 7A} 4D] C2] 6E] FO] 5D] 

to bh 
0 8 16 24 32 40 48 56 64 72 


The second portion of this table contains 
the expression area in compact literal form 
(excess blanks and characters eliminated). 
This portion of the table is introduced 
with a dollar sign ($). 


12.1.11 TABLE 7 (USER-EXIT LIST) 


This table is in a format identical to 
Table 4 and contains the program list 
defined following the keyword EXIT. The 
table, when present, always contains three 
entries. 


12.1.12 TABLE 8 (VERB PROGRAM LIST) 


This table is in a format identical to 
Table 4& and contains the program list 
defined following the term VERB at phrase 
definition time. 


12.2.0 PLAN FILE CONTROL BLOCKS 


The following charts provide the content of 
the PLAN DYNAMIC file control blocks. Note 
that because of the integer word size 
differences (16-bit versus 32-bit), the 
1130 PLAN system has a different format 
from that of the System/360 OS or DOS PLAN. 
The table given below provides the format 
for the System/360 OS/DOS PLAN. 


ID(1) TD(2) 

{| | 

1 Of TTR | DBD | N | Sf 

ens Eee eeeer pes, ee mtr nent [ae ey J 

0 1 20 23 24 31 32 63 

TTR This 19-bit field contains the TTR 
of the FDR for this file. 

D This three-bit (<8) field contains 
the logical drive code for this 
file. 

N This 8-bit (<256) field contains the 
file identification number. This 


field is originally set by the user 
before issuance of the CALL FIND. 
All other fields within ID(1) are 
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set as a result of CALL FIND or CALL 
WRITE operations. 


Ss This 32-bit field contains the 
rent size of the file in words. 


cur- 


The following chart defines the 1130 DYNAM- 
Ic file control block: 


ID(1) 


0 45 78 15 16 19 20 31 32 47 48 56 


R (reserved) 

Pp This three-bit field contains the 
file priority. 

N (see above) 

D (see above) 

F 


This twelve-bit (<640) field con- 


tains the physical address of the 
first record in the last extent 
accessed. 

Ss (see above) 

A This eight-bit (<50) field contains 
the relative allocated segment num- 
ber of the first segment of the last 
extent accessed. 

Cc This eight-bit (<50) field contains 


the number of contiguous segments in 
the current extent. 


The following charts define the format of 
the PERMANENT (GDATA, RDATA, WDATA) file 
control blocks. The file ID number is. set 
by the user before issuing the CALL GDATA. 
All other fields are defined as a result of 
the CALL GDATA and are modified by CALL 
RDATA. 


System/360 OS/DOS PLAN 


ID(1) ID(2) 

I | | i | | 

| 00 | TF | D | N | Ss | 

Re Me es E ere een Bde oe J 

0 7 8 15 16 23 24 31 32 63 

D This eight-bit (<8) field indicates 
the logical drive code as 0-7. 

N This eight-bit (<64) field contains 
the number of the file. 

Ss This 32-bit field contains the size 


of the file in 32-bit words. 
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IBM 1130 PLAN 


ID(1) ID(2) 
I | 1 | | [ | | 
| |DISK | {(Nor | 
|7F(HEX)| N  [1]LDR |ADDRESS| S | USED)| 
ee OR esc a ee A Cerone i heres J 
0 78151617 20 21 31 32 46 47 63 
LDR This four-bit field contains the 


logical drive code. 
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13.0.0 APPENDIX F: 


This appendix contains a discussion of the 
control of diagnostic processing and lists 
diagnostic messages generated by various 
PLAN components through linkage to the 
error processor PERRS. The format of PLAN 
system diagnostics is shown below: 


DFJO00 001-100 TEXT 

101-200 TEXT 

201-300 TEXT 

301-400 TEXT 

401-450 TEXT 
CccCnnn *A* muammm SEQ=yyy ID=ccccc 
PG=xXXXXXxXxx DIAGNOSTIC 














The segments of the diagnostic message 
underlined in the above example are vari- 
able. Functions defined by the variable 


data are: 


This field of up to five lines 
contains the current input 
statement. It is printed only 
if the long-form diagnostic is 
requested (see "Switch Words", 
4.3.22). Character positions 
are printed to the left of the 
text. 


TEAT 


ccc This three-character field is 
DFJ if the diagnostic is 
generated by PLAN and *** if 


generated by the user. 


nnn This three-digit number is the 
error number assigned by the 
call to the error routines as 
calling parameter N1. In PLAN 
error diagnostics, this number 
is merely a diagnostic modifi- 
er (index). 


[> 


This character specifies the 
action taken following genera- 
tion of the literal. 


R indicates that execution 
of the current command is 
terminated. PLAN error 
recovery is initiated. 


Cc indicates that following 
generation of the diag- 
nostic, the execution of 
the current command is 
continued. 


E indicates that the current 
execution of PLAN is 
terminated. 


DIAGNOSTIC 
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PLAN SYSTEM DIAGNOSTIC PROCESSING 


O indicates a pause for 
operator intervention. 

rammmnm This is a five-digit modifier 
(ECODE) that provides addi- 
tional information about the 
error. This parameter is pro- 
vided as N2 in the call to the 
PLAN error subroutines. 


This field provides the state- 
ment sequence of this PLAN 
statement relative to the 
beginning of the PLAN job 
stack. 


SEQ=yyy 


ID=ccccc This five-character field pro- 
vides the identification field 
(cc. 76-80) of the last card 
of the current PLAN statement. 
PG=XXxXxxxxx This field provides the name 
of the program in execution at 
the time the call to the error 
routine is issued. 


This field contains the liter- 
al text of the diagnostic mes- 
sage and is limited to 76 
characters. 


13.1.0 PLAN ERROR PROCESSING 


Since the PLAN system is a monitor which 
supervises the execution of other problem 
programs, it must have the ability to 
detect abnormal conditions. 
There are four types of errors the PLAN 
system can detect and these are: 


e Phrase Definition Errors 
e Command Errors 
e Execution Errors 
'e@ User-Defined Errors 
1. Phrase definition errors are detected 
by the PLAN system module “PHRAS" when 
a phrase is being entered into the PLAN 
language dictionary. 
2. Command errors are detected by the PLAN 


system module “PSCAN" while processing 
commands. 
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3. Execution errors are detected by the 
PLAN system mainline while a problem 
program is in execution. 


4. User-defined errors are the result of a 


programmed call to one of the error 
subroutines (ERROR, ERRET, ERREX, 
ERRAT). 


Each type of error discussed is detected by 
a different module and at a different point 
in time. The technique used to produce a 
diagnostic in this environment may be 
described as follows: When an error is 
detected by any component of the system, 
the type of error is recorded and a genera- 
lized diagnostic processing module is 
called to produce the required error mes- 
sage. The PLAN system module that produces. 
diagnostic messages is "PERRS". 


The PLAN system offers the user several 
options in processing errors. Several 
terms are defined below that are used in 
describing these options.. 


SHORT FORM. 
produced without printing the 
caused it. 


The diagnostic message is 
phrase that 


LONG FORM. The phrase that caused the 
diagnostic is printed with the diagnostic 
message. 


IMMEDIATE MODE. The error processing 
module “PERRS" is invoked at the time the 
error occurs, even if a checkpoint is 
required. 


STACKED MODE. A condensed version of the 
error is recorded in the error message 
stack which will be processed the next time 
"PERRS" is invoked by the system. 


ERROR MSG __ STACK. An area on PFILE is 
reserved exclusively for recording errors 
in a condensed form. This gives the system 
the ability to delay calling the diagnostic 
processor “PERRS" until the program area is 
available. 


ERROR MSG QUEUE. DYNAMIC file 255 on PLAN 
DYNAMIC drive 0 is reserved as a queue area 
for diagnostic messages. This gives the 
system the ability to post-list diagnostic 
messages by writing the messages on the 
file as they occur and then dumping the 
file on command. 


USER-ERROR EXIT. The PLAN system has the 
ability to call a user-error processing 
module in the cases where the normal PLAN 
mode of diagnostic presentation is not 
appropriate for the application. 
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13.2.0 SPECIFYING ERROR PROCESSING MODE 


The mode of error processing by the PLAN 
system is controlled by the PLAN Switch 
Words 11, 12, and 13. These switch words 


can be set by any PLAN’ command. The 
standard error processing mode is as 
follows: 


1. Errors are stacked. 
2. Error message format is short. 


3. No error messages are queued for 


post-listing. 


4. No user-error processing module 
will be called. 
5. Messages are printed on the stand-~ 


ard PLAN output device. 


6. Errors detected by the PLAN DYNAMIC 
file routines cause a phrase abort. 


7. #$j&Errors detected by the PLAN PER- 
MANENT file routines cause a phrase 
abort. 


Switch Words 11-13 are normally set by the 
following operands of the PLAN JOB command: 


1. WNERM 
2. DEVICE 
3. UMOD 
4. SHORT 
5. LONG 
6. STACK 
7. j.XIMM 

8. DFI 

9. PFI 


NERM specifies the number of error messages 
to be written on the error message queue 
file before they are dumped on the error 
message device. 


DEVICE specifies the sequential file device 
code (NOD argument for PLINP/PLOUT subrou- 
tines) to which the diagnostic messages are 
to be written. 


UMOD specifies the EBCDIC name of a_euser- 
error processing module to be called by the 
error processor "PERRS" when an error is 
processed. 


SHORT specifies that the SHORT form of the 
diagnostic is to be used when an error 
message is produced. 


LONG specifies that the LONG form of the 
diagnostic message be used when an error 
message is produced. 


STACK specifies that the system is to 
optimize error message processing by using 
the error message stack in PFILE to record 


15 SEPTEMBER 1969 


messages until "PERRS" can be called 


without a checkpoint. 


IMM specifies that "PERRS" is to be invoked 
at the time the error occurs. 


DFI specifies that a phrase abort condition 
is not to occur on certain error conditions 
detected by the DYNAMIC file support sub- 
routines routines (see "DYNAMIC File Rou- 
tines", 5.11.0). 


PFI specifies that a phrase abort condition 
is not to occur on certain error conditions 
detected by the PERMANENT file support 
subroutines (see "PERMANENT File Routines", 
5.11.3). 


If both SHORT and LONG are specified, the 
LONG-form option is used. If both STACK 
and IMM are specified, the IMMEDIATE option 
is used. 


Use of the operands PFI and DFI requires 
the application program to process’ the 
error conditions that would normally abort 
the PLAN statement. If these operands are 
specified and the required programming is 
not present, unpredictable results can 
occur. What generally takes place is the 
following: When the error is detected the 
file control block is closed, and on the 
next reference to the file, an error mes- 
sage indicating an unopened file control 
block is issued. This masks the real 
reason for the error condition. 


13.3.0 STANDARD ERROR PROCESSING 


Normally, the PLAN system will process 
errors at SHORT form and in a stacked mode. 
The reason for using this technique is that 
the size of the PLAN error processing 
module is such that if the program area is 
not free, a checkpoint is required to load 
and execute "PERRS". Delaying the call to 
“PERRS" until the program area is free 
eliminates the need for a checkpoint and so 
improves performance. The error message 
stack has a finite limit on the number of 
messages it can contain, and in cases where 
the stack overflows, a checkpoint is forced 
and “PERRS" empties the stack. 


13.4.0 POST LISTING OF ERRORS 


Some applications may require that error 
messages be suppressed until end of job. 
An example of this is a compiler, such as 
FORTRAN or COBOL, where the error messages 
are listed at the end of the compilation. 
The PLAN system provides this facility to 
the user as a standard option. In order to 
use this facility the PLAN system must have 
available PLAN DYNAMIC drive 0. DYNAMIC 
file 255 is used as an error message queue 
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file. To invoke this facility the user 
must specify a value in system Switch Word 
11. 


The value in this switch word is used by 
the error processor "“PERRS" to determine 
the number of error messages to write on 
the error message queue file (drive 0, file 
255) before dumping the file on an output 


device. 


The message records on this file are writ- 
ten as 21-word or 124-character records. 
The first word of the record is an integer 
from -3 to +12, and is used as an argument 
for the PCCTL subroutine to effect carriage 
control for the data line that is contained 
in words 1-24 (characters 4-123). The data 
portion must be alphameric data in the A4& 
format. The data area of records produced 
by “PERRS" contains the PLAN system diag- 
nostic message text. The user may write 
records directly to this file from an 
application program by using the PLAN sub- 
routine EWRIT (see “Error Interface Subrou- 
tines", 5.11.6). 


The PLAN error message queue file is dumped 
on the diagnostic device under the follow- 
ing conditions: 


1. The number of diagnostics messages 
added to the queue file exceeds 
NERM. 


2. The subroutine ERLST is called. 


3. The end of PLAN input (/*) is read 


by PSCAN. 


4. A level 0 phrase is processed. 


5. A level 1 phrase is processed. 


13.5.0 USER-ERROR EXIT PROCESSING 


If a user module name is specified in 
system Switch Words 11 and 12, by specify- 
ing UMOD‘NAMES, the PLAN error processor 
PERRS creates an array in ERASABLE COMMON 
that describes the error and then invokes 
the named module through the PLAN LOCAL 
facility. This array is in the following 
format: 
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BYTE CONTENTS 

0-7 Program name issuing diag- 
nostic call 

8-11 Error number (N1 from error 
subroutine call) 

12-15 Error code (N2 from error 
subroutine call) 

16-20 ID from cc. 76-80 


21 hexadecimal FF=system error, 
O=user error 


22 hexadecimal FF=abort, 
0=continue 
23 (unused) 
24-27 Sequence 
28-31 Length of literal in 
characters 


32-107 Literal text 
108-111 Character count of phrase 
112-561 Phrase text 


A program written aS a user-error processor 
may not use the following PLAN subroutines 
ERROR, ERRAT, ERREX, ERRAT, ERLST, LREPT, 
LCHEX, LREPT, and PUSH. Any error detected 


while a user-error processing module is in 
control causes cessation of all error 
processing. 


The UMOD and the NERM or DEVICE specifica- 
tions are mutually exclusive. Therefore, 
the automatic PLAN facility for post- 
listing of errors (as described in 13.2.0) 
is not available, if a user-error proces- 
Sing module is used. The same effect may 
be produced, however, by using the subrou- 
tine EWRIT to create an error message queue 
file. A dump of the file may be forced by 
using the LIST subroutines’ to place the 
name PEDMP into the pop-up list. This 
module will force a dump of the error 
message queue file and will also terminate 
the current statement. 


13.6.0 PHRAS DIAGNOSTICS 


The following diagnostics are generated 
from errors detected by PHRAS (the ADD 
PHRASE processor). ECODE (m) for all diag- 
nostics generated by PHRAS is a pointer to 
the position at which the error condition 
was detected, except as otherwise noted. 
Position one is the first character of the 
command. The format of the descriptions of 
the diagnostics is: 


e DIAGNOSTIC NUMBER(n), 
DIAGNOSTIC e 
REASON 


ACTION CODE, 


® 21 *C* PHRASE TO DELETE CANNOT BE FOUND e 
A phrase that is to be deleted is not 
currently in PFILE. This can result from 
a DELETE PHRASE or an ALTER PHRASE. If 
it results from an ALTER PHRASE, the ADD 
PHRASE aspect of the command is not 
suppressed. 
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e 22 *R* NO ROOM TO ADD PHRASE ° 
There is no contiguous vacant area in 
PFILE large enough to allow the current 
phrase to be added. PFILE must be reor- 
ganized, reestablished, or expanded. 
Usually, some space can be gained by 
reorganizing the file without changing 
its size. This is accomplished by delet- 
ing the phrases and then re-adding them. 


Additional phrases may be provided for by 
enlarging PFILE if it is currently small- 
er than the maximum size. PFILE must be 
at least 14 sectors (17 sectors on 1130 
PLAN) and not more than 268 (205 on 1130 
PLAN) sectors in length. This will. also 
require that the phrases for the system 
be re-added 


e 23 *R* PHRASE ALREADY DEFINED ® 

An attempt to adda phrase that already 
exists in PFILE has been made. If the 
phrase to be added is a replacement for 
the existing phrase, the existing phrase 
must be deleted (DELETE PHRASE or ALTER 
PHRASE, see 4.5.1 and 4.5.3) before the 
new phrase can be added. 


e 24 *R* INVALID FORMAT IN PROGRAM LIST e 
A program list defined with the ADD 
(ALTER) PHRASE is found to contain inval- 
id syntax. This can result from an 
unrecognizable numeric or special 
character 


e 25 *R* INVALID FORMAT IN USER-EXIT PRO- 
GRAM LIST e 
This error may result from: 
a. A program name not starting with an 
alphabetic character 
b More than three programs in the list 


(Note that errors in the user-exit pro- 
gram list may also be diagnosed as error 
number 24.) 


e 26 *R* KEYWORD ENTRY NOT TERMINATED BY 
COMMA OR SEMICOLON e 
A keyword (symbol table entry, PROG, 
VERB, EXIT, or LEVEL) has been collected, 
but the keyword and associated data was 
not terminated with a comma or semicolon. 


e 27 *R* LEVEL NUMBER GREATER THAN 4 e 
The number collected following the speci- 
fication word LEVEL is greater than 4. 


e 28 *R* NO SYMBOL DEFINED AFTER EXECUTION- 
DEFINED SYMBOL SUBSCRIPT EXPRESSION ¢ 
A symbolic subscript expression requires 
a symbol (name) to be defined. The 
required symbol has not been found. 


e 29 *R* CONSTANT SUBSCRIPT ZERO OR LESS 
THAN -15 e 
A constant subscript has been encountered 
that does not describe a valid location 
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in the system switch words or communica- 
tion array. 


30 *R* IMPLIED DO SUBSCRIPT NOT FOLLOWED 
BY SINGLE-VALUED CONSTANT e 

The value following an implied DO sub- 
script was not found to be ae single- 
valued constant, that is, numeric, +, or 
-. This error can result from an implied 
DO subscript followed by: 


a. A literal default, that is, "ABC" 
b. No default value 


31 *R* SYMBOL SUBSCRIPT GREATER THAN 8176 
OR 511 WITH P-VALUE °« 

A constant subscript that defines a sym- 
bol exceeds the maximum allowable value 
of 8176 without scale values (P values) 
or 511 with scale values. 


32 *R* EXECUTION-DEFINED SYMBOL FOLLOWED 
BY IMPLIED SYMBOL °¢ 

A symbol that is implied follows a symbol 
associated with a symbolic (execution- 
defined) subscript. There may not be an 
implied symbol after a symbolic 
subscript. 


33 #R* PHRASE DEFINITION INVALID e 

A phrase is not defined properly, that is 
the phrase name is syntactically incor- 
rect. This can be caused by: 


a. Failure to end the phrase definition 
with a comma 

b. Use of nonalphabetic characters within 
the phrase definition 


34 *R* SUBSCRIPT FOR DATA VALUE GREATER 
THAN 16,368 e 

A communication array subscript greater 
than 16,368 has been encountered. 


35 *R* INVALID CHARACTER e 

The ECODE pointer indicates a character 
that is invalid in a phrase definition. 
This error can result from an error 
within the phrase further to the left 
that was undetectable at that phase of 
the scan. 


36 *R* BCD LEFT PARENTHESIS IN LOGICAL 
EXPRESSION e 

All characters in a logical expression 
must be punched in the EBCDIC code. 


37 *R* USER-EXIT NUMBER GREATER THAN 3 e@ 
User exits must be 1, 2, or 3. 


38 *R* FORMULA NUMBER USED BEFORE FORMULA 
AREA e@ 

A conditional exit includes a formula 
number, but a $n introducing the expres- 
sion area has not been encountered. 


39 *R* FORMULA NUMBER ZERO OR GREATER 
THAN 1024 e 
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The valid range for formula numbers is 
from 0 to 1024 in a phrase definition. 


GO *R* UNDEFINED FORMULA NUMBER IN FORMU- 
LA AREA e 

A transfer type formula has been encoun- 
tered that references a nonexistent for- 
mula number. ECODE is set to the formula 
number found to be in error. 


41 *R* MULTIPLE DEFINITION OF 
NUMBER IN FORMULA AREA @ 
More than one formula is identified with 
the same number within this phrase. 


FORMULA 


42 *R* INVALID FORMAT IN FORMULA AREA e 
Formula numbers must be followed by: 

a. Another formula number 

b. Expression 

c. Symbol 

d. Semicolon 

e. Comma 


43 *R* P-VALUE GREATER THAN 7 e 

A scale factor greater than plus seven or 
less than minus seven has been 
encountered. 


44 *R* KEYWORD ‘PROGRAMS‘ NOT FOLLOWED BY 
PROGRAM LIST e 

A program specification has been encoun- 
tered, but a program list is missing. 
This can result from the next significant 
character not being a quotation mark, 
double quote, or commercial at sign. 


45 *R* INVALID 

EXPRESSION e 

A syntax error has been encountered in a 

relational expression. Possible reasons 

for this error are: 

a. Unbalanced parentheses 

b. A semicolon invalid within (not at end 
of) an expression 


FORMAT IN RELATIONAL 


46 *R* PROGRAM NAME CONTAINS TOO MANY 
CHARACTERS e 

The maximum allowable length for a pro- 
gram name is eight characters on Systen/ 
360 or five characters on the 1130. 


47 *R* SEMICOLON IN LITERAL OR EMPTY 
LITERAL ¢ 

A semicolon is an invalid literal 
character. This diagnostic may result 
from failure to include the terminal 
quotation mark of a literal. The phrase 
terminating semicolon may then appear to 
be within the literal. A zero-length 
literal is invalid. 


48 *R* INVALID FORMAT IN SYMBOLIC SUB- 
SCRIPT EXPRESSION e 

The indicated position contains a 
character that forms an invalid context 
for a subscript (arithmetic) expression. 
These conditions include: 

a. Adjacent arithmetic operators 
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b. Unmatched parenthesis 
c. Invalid characters 
d. Expression does not end with comma 


49 *R* USER EXITS NOT ALLOWED ON NEGATIVE 
SUBSCRIPTS e 

An attempt has been made to define a user 
exit to store data in the switch area. 

50 *R* INVALID FORMAT IN LOGICAL OR 
ARITHMETIC EXPRESSION e 

ECODE points to a character that may not 
be contained in the context of a logical 
or arithmetic expression. These condi- 
tions include: 

a. Adjacent arithmetic operators 

b. Unmatched parenthesis 

c. Invalid characters 

d. Expression does not end with comma 


51 *R* INVALID 
EXPRESSION e 
The indicated position contains a 
character that forms an invalid context 
for a subscript (arithmetic) expression. 
These conditions include: 

a. Adjacent arithmetic operators 

b. Unmatched parenthesis 

c. Invalid characters 

d. Expression does not end with comma 


FORMAT IN SUBSCRIPT 


52 *R* EXPRESSION SUBSCRIPT GREATER THAN 
8176 OR 511 WITH P-VALUE ® 

The symbolic subscript that is associated 
with a phrase-defined expression is 
greater than 8176 (if a scale factor is 
not defined) or greater than 511 (if a 
scale factor is defined). 


58 *R* NUMBER OUTSIDE ALLOWABLE FLOATING- 
POINT RANGE e 
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a. The increment (I3) is negative. 

b. The limit (I3) is negative. 

Cc. The limit divided by the increment is 
not a whole number. 

dad. (Ig) or (Is) is not a 
constant. 


numeric 


68 *R* LEG OF CONDITIONAL EXPRESSION NOT 
EXPRESSION OR FORMULA NUMBER e 


The TRUE action leg or FALSE action leg 
Of a conditional expression is not an 
expression (example: ?=B#100) or a_ for- 
mula number (example: ?5$5). 


70 *R* CHECK-ENTRY SUBSCRIPT GREATER THAN 
8176 e 

The constant subscript that is associated 
with a check entry is greater than 8176. 


71 *R* INVALID FORMAT IN 
LITERAL ® 

A check entry must be in the following 
format when the literal option is 
exercised: 


CHECK~ENTRY 


*A‘* LITERAL‘ 
*C' LITERAL‘ 
*RC (SUBSCRIPT) 


The following condition may have been 
detected: 

a. A semicolon within the literal 

b. Quotation marks unmatched 

c. A subscript greater than 16,383 


72 *R* UNBALANCED PARENTHESIS IN PROGRAM 
LIST e 

An unequal number of left and right 
parentheses have been found ina program 
list. 


A number has been given that cannot be 
represented in the floating-point repre- e 80 *C* UNREFERENCED FORMULA NUMBER IN 
sentation of the PLAN system. The maxi- FORMULA AREA **UPDATE NOT SUPPRESSED** e 

mum limit is 2127 and the minimum limit The formula area has been found to con- 
is 2-128 on the 1130. On System/360 the tain a formula number that is not 
Maximum limit is 16°? and the minimum referenced in another expression. ECODE 
limit is 167-63, defines the formula number that is 

unreferenced. 
e 64 *R* PHRASE ENTRY TOO LARGE e 

The total phrase size is greater than 
1024 bytes and will not be added, or one 
of the eight internal phrase tables is 
longer than 512 bytes. ECODE is either 
the total size of the phrase or the PFILE 


13.7.0 EXECUTION-TIME DIAGNOSTICS 


The following errors are detected during 
internal table number (see 12.1.5 to execution of logic modules operating within 
12.1.12) that is too large. the PLAN environment. All 100 series 
errors result in a PLAN "Phrase Abort" and 
subsequent level error recovery. The for- 
mat of the definitions for this section is: 


e 65 *R* ILLEGAL SYMBOL - CANNOT BE ‘E* © 
A data name has been defined to be E. E 
is not allowed because of syntactical 
confusion with the exponential indicator ® NUMBER *ACTION CODE* DIAGNOSTIC e 
E. PROGRAM INDICATED 
ECODE MEANING 
e® 66 *R* INVALID FORMAT IN REASON FOR ERROR 
SUBSCRIPT e 
A syntactical error has been encountered. 
Reasons for this diagnostic may be: 


IMPLIED DO 


® 101 *R* PROGRAM 
LIBRARY e 


NAMED NOT IN PLAN 
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Program: Program name not found 

ECODE: Unused. 

Reason: The named program was not in 
the search of the PLAN library 


102 *R* INVALID COMMON DEFINITION 

ENCOUNTERED e 

Program: Program name. 

ECODE: Unused. 

Reason: The length of COMMON for the 
named program is less than 640 
FORTRAN (32-bit) words. 


103 *R* PROGRAM TOO LARGE FOR AVAILABLE 

MEMORY e 

Program: Program name. 

ECODE: Unused. 

Reason: a. The size of the named 
program exceeds the size of 
the available area for pro- 
gram loading. 

b. This message may be given by 
PSCAN if a program to be 
loaded as a user-exit pro- 
gram would overlay PSCAN 
(1130 only). 


104 *R* PROGRAM NAME IN INVALID FORMAT e 

Program: ‘eeeeesecse* (Unpredictable) 

ECODE: Unused. 

Reason: An invalid program name _ has 
been found in the pop-up list. 


105 *R* PROGRAM FORMAT INVALID ° 

Program: Program name. 

ECODE: Unused. 

Reason: The named program is in over- 
lay, scatter mode or contains 
TESTRAN symbol cards on OS PLAN 
or is not in core image format 
on 1130 PLAN. 


110 *R* CHECKPOINT PROCESSING INVALID e 
Program: Last program entered. 
ECODE: Unused. 
Reason: a. An * encountered without a 
checkpoint being in effect. 
b. A checkpoint call when ei- 
ther there is no checkpoint 
file or insufficient room to 
write the complete 
checkpoint. 
ce. A program to be check- 
pointed has been overlaid by 
COMMON (DOS only). 
‘ad. LCHEX subroutine is not in 
the calling module (DOS 
only). 


111 *R* OVER 50 NAMES IN POP-UP LIST e 

Program: Last program entered. 

ECODE: Unused. 

Reason: An attempt to place more than 
50 names in the pop-up list has 
been made. 


112 *R* LOCAL PROCESSING INVALID e 
Program: Program issuing CALL LOCAL. 
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ECODE: Unused. 
Reason: a. There is not room to load 
the program called as a 
LOCAL. 
b. LOCAL caller overlaid by 
program named (DOS only). 
c. LOCAL caller overlaid by 
COMMON (DOS only). 
d. LOCAL subroutine not in the 
calling module (DOS only). 
e. LOCAL caller is itself a 
PLAN LOCAL (1130 only). 


e 113 *R* LSAV OR LRLD PROCESSING INVALID e 
Program: Program issuing loader call. 
ECODE: Unused. 

Reason: A second CALL LSAV has been 
processed without an interven- 
ing CALL LRLD or aocall toa 
loader function has been proc- 
essed without the loader in 
memory . On System/360 all 
calls to LSAV or LRLD are 
invalid. 


Note: In all 120-130 series diagnostics 
ID(1) is set to a closed status. Any 
further attempt to read or write to the 
file without reopening the file will result 
in a phrase abort, and PLAN level error 
recovery will be invoked. 


® 120 *R* UNOPENED FILE CONTROL BLOCK ON 
CALL READ/WRITE e 
Program: Last program entered. 
ECODE: File number. 
Reason: ID(1) in the file control block 
is in a closed status. 


e 122 *R* INVALID DRIVE CODE OR FILE CON- 
TROL BLOCK ON CALL FIND/RELES e 


Program: lLast entered. 
ECODE: Unpredictable. 
Reason: a. File number is zero. 
b. Drive code is negative or 
greater than 7 (DOS/OS) or 
greater than 4 (1130). 


e 123 *R* INVALID FILE CONTROL BLOCK ON 
CALL READ/WRITE e 
Program: Last program entered. 
ECODE: Unpredictable. 
Reason: a. ID(1) has been altered. 

b. The file specified by ID(1) 
has been released because of 
an allocation request for a 
higher-priority file. 

c. The file specified by ID(1) 
was automatically released 
because a phrase of higher 
priority than the file was 
processed. This can apply 
only to ID control blocks 
that reside in COMMON 
through phrase boundaries. 

d. The file control block for 
PFND1 support may not have 
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been located on an even word 
boundary. 


KDIS/KOUNT ON CALL 

READ/WRITE e 

Program: Last program entered. 

ECODE: File number. 

Reason: KDIS or KOUNT is negative of 
KDIS+KOUNT exceeds maximum file 
size (32,767 on 1130). 


125 *R* DYNAMIC DRIVE NOT MOUNTED e 

Program: Last entered. 

ECODE: File number. 

Reason: A DYNAMIC drive required by a 
CALL FIND/READ/WRITE/RELES is 
not available to the system. 


126 *R* INSUFFICIENT SPACE FOR ALLOCATION 

ON CALL FIND/WRITE e 

Program: Last entered. 

ECODE: File number. 

Reason: a. On a CALL FIND insufficient 
space is available to satis- 
fy the NALLO argument. 

b. On a CALL WRITE insufficient 
space is available for 
secondary allocation. 


128 #R* PACK ID NOT EQUAL ON VALIDITY 

CHECK e 

Program: Last entered. 

ECODE: File number. 

Reason: (1130 only) A request for pack 
verification has resulted ina 
test failure. 


129 *R* PFIND NOT IN PLAN LIBRARY e 

Program: Last program entered. 

ECODE: File number. 

Reason: PFIND was not found at PLAN 
initialization time, and a sub- 
sequent call to FIND, READ, 
WRITE, FINDL, PFSPC, or RELES 
has been processed (on 1130 
PLAN only). 


130 *R* UNOPENED FILE CONTROL BLOCK ON 

CALL RDATA/WDATA e 

Program: Last program entered. 

ECODE: File number. 

Reason: ID(1) in the file control block 
was not initialized. 


132 *R* INVALID DRIVE CODE OR FILE CON- 
TROL BLOCK ON CALL GDATA e 


Program: Last entered. 
ECODE: Unpredictable. 
Reason: a. File number is zero. 
b. Drive code is negative or 
greater than 7 (DOS/OS) or 
greater than 4 (1130). 
c. File name is not in PLAN 
library. 


133 *R* INVALID FILE CONTROL BLOCK ON 
CALL RDATA/WDATA e 
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Program: Last program entered. 
ECODE: Unpredictable. 
Reason: ID(1) has been altered 


134 *R* INVALID 

RDATA/WDATA e 

Program: Last program entered. 

ECODE: File number. 

Reason: KDIS or KOUNT is negative or 
KDIS + KOUNT exceeds the maxi- 
mum file size (32,767 on 14130). 


KDIS/KOUNT ON CALL 


135 *R* PERMANENT DRIVE NOT FOUND e 

Program: Last program entered. 

ECODE: File number. 

Reason: The DYNAMIC drive is not 
defined or cannot be found on 
this system. 


140 *R* INVALID RECORD LENGTH ON CALL 

PSORT/PMERG ¢ 

Program: PSRTA 

ECODE: File number. 

Reason: Word 1 of the sort control list 
is minus or greater than 512. 


141 *R* INVALID SORT CONTROL FIELD COUNT 

ON CALL PSORT/PMERG « 

Program: PSRTA 

ECODE: File number. 

Reason: The number of sort fields is 
specified as negative, zero, or 
greater than 99 or extends 
beyond the end of COMMON. 


142 *R* INVALID SORT CONTROL FIELD ON 

CALL PSORT/PMERG e 

Program: PSRTA 

ECODE: File number. 

Reason: a. Word 1 of the sort control 
field is out of range (-6 to 
+6). 

b. Boundary alignment of 
displacement is invalid for 
type of sort. 

c. The sort field extends 
beyond the length of the 
record. 

d. The number of element speci- 


fied is not a positive 
integer. 
143 *R* INSUFFICIENT FILE SPACE TO 


EXECUTE PMERG FUNCTION e 

Program: PMRGA 

ECODE: Merge file number. 

Reason: The required space for the out- 
put file of the merge is not 
available. 


144 *R* INSUFFICIENT WORK AREA IN MANAGED 
AREA FILE FOR PSORT FUNCTION e 

Program: Program calling PSORT. 

ECODE: File number. 

Reason: Self-explanatory 
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Note: This can also result from a call to 
PMERG on 1130. 


e 145 *R* MERGE FILE OUT OF SEQUENCE ON 
CALL PMERG e 
Program: PMRGA 
ECODE: File number. 
Reason: Self-explanatory. 


e 146 *R* UNOPENED FILE CONTROL BLOCK ON 
CALL PSORT/PMERG e 
Program: Program calling PSORT/PMERG 
ECODE: File number. 
Reason: The file control block speci- 
fied is found not to be proper- 
ly opened. 


e 147 *R* FILE TO SORT DOES NOT EXIST e 
Program: PSRTA 
ECODE: File num. 
Reason: Specified file cannot be found 
on the drive specified in the 
file control block. 


e 1468 *R* DRIVE CONTAINING FILE Not 
AVAILABLE e¢ 
Programs PSRTA 
ECODE: File number. 
Reason: The drive specified by the file 
control block is not available 
(1130 only). 


e 150 *R* INVALID RECORD LENGTH ON CALL 
GSORT/GMERG e 
Program: Last entered. 
ECODE: Record length. 
Reason: Word 3 of the sort control list 
is minus or greater than 512 
(System/360 only). 


® 151 *R* INVALID SORT CONTROL FIELD COUNT 

ON CALL GSORT/GMERG e 

Program: Last program entered. 

ECODE: Sort field count. 

Reason: The number of sort fields is 
specified as negative, zero, or 
greater than 98 (System/360 
only). 


e 152 *R* INVALID SORT CONTROL FIELD ON 
CALL GSORT/GMERG e 
Program: Last program entered. 


ECODE: Sort control field sequence. 
Reason: a. Word 1 of the sort 
control 


field is out of range (-6 to 
+6) (System/360 only). 

b. Boundary aligment of 
displacement is invalid for 
type of sort. 

c. The sort field extends 
beyond the length of the 
record. 

d. The number of elements spec- 
ified is not a positive 
integer. 
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153 *R* INSUFFICIENT FILE SPACE TO 


EXECUTE GMERG FUNCTION e 

Program: Last program entered. 

ECODE: Merge file number. 

Reason: The required space for the 
merged file is not available 
(System/360 only). 


154 *R* INSUFFICIENT WORK AREA IN MANAGED 
AREA SAVE FILE FOR GSORT FUNCTION e 
Program: Program detecting the error. 


ECODE: File. number. 
Reason: Self-explanatory (System/360 
only). 


155 *R* MERGE FILE OUT OF SEQUENCE ON 
GMERG e 
Program: Program detecting the error 


ECODE: File number. 
Reason: Self-explanatory (System/360 
only). 


156 *R* UNOPENED FILE CONTROL BLOCK ON 

CALL GSORT/GMERG e 

Program: Program calling GSORG/GMERG 

ECODE: File number. 

Reason: The file control block spec- 
ified is found not to be prop- 
erly opened (System/360 only). 


171 *R* INVALID SAVED STATEMENT EXECUTION 

FILE e 

Program: PSTSV 

ECODE: File number. 

Reason: The header of the indicated 
file is found not to be valid 
for a statement save file. 


172 *R* STATEMENT TO EXECUTE NOT IN SAVE 
FILE e 
Program: PSTSV 


ECODE: The number of the statement to 
be executed from the save file. 
Reason: A statement has been indicated 


for retrieval from the state- 
ment save file but cannot be 
found. 


173 *R* PROGRAM ERROR IN SAVED STATEMENT 

RETRIEVAL e 

Program: PSTSV 

ECODE: The invalid value causing the 
error. 

Reason: The saved statement file has 
been destroyed or overwritten. 


180 *R* INVALID LITERAL FILE e 

Program: PDIAG or PLITL 

ECODE: The file number. 

Reason: A file defined for literal 
processing cannot properly be 
opened by GDATA. 
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13.8.0 PSCAN DIAGNOSTICS 


The following diagnostics are generated as 
a result of errors detected by PSCAN while 
processing the phrases and language defini- 
tion file (PFILE). 


e 201 *R* PHRASE SKIPPED e 

ECODE: Unused. 

Reason: PSCAN has caused the statement to 
be bypassed because of an error 
in a preceding command upon which 
this command is dependent. 

Action: The next command is processed. 


e 210 *R* LEVEL 0 PHRASE NOT ENCOUNTERED ¢ 


ECODE: Cursor.. 
Reason: A level 0 phrase was not 
encountered following the 


invoking of PLAN. 
Statements are skipped until a 
level 0 phrase is encountered. 


Action: 


e 220 *R* LEVEL 1 PHRASE NOT ENCOUNTERED ¢@ 

ECODE: Cursor 

Reason: The first recognizable command 
in a job stack depends logical- 
ly on a statement that was not 
found. The preceding 
statement(s) may have resulted 
in a code 221 diagnostic. 
Statements are skipped until a 
level 1 phrase is encountered. 


Action: 


e 221 *R* UNDEFINED PHRASE e 

ECODE: Cursor. 

Reason: The command cannot be recog- 
nized in total or in part as a 
phrase defined in the systems 
dictionary. The statement scan 
is abandoned. 

The scan of this 
terminated. 


Actions command is 


e 222 *R* STATEMENT OVER 450 CHARACTERS e 
ECODE: Cursor. 
Reason: A semicolon may be mispunched 
or missing. 
Statement scan is terminated. 
Only that portion of the com- 
mand read as the last record is 
printed as command text when 
long-form diagnostics are used. 
The position will be identified 
as positions 001-100. 


Action: 


e 223 *R* PLAN WORD FALSE °® 
ECODE: A subscript indicating the par- 
ticular communication array 
location that was tested for 
not FALSE. 
Reason: The tested location was found 
to be FALSE. 
Level error recovery and 
ping is initiated. 


Action: skip- 
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e 224 *R* 


ECODE: 


Reason: 


Action: 


225 *R* 
ECODE: 
Reason: 
Action: 
226 *R* 
ECODE: 
Reason: 
Actions 
227 *RF 
STREAM e 
ECODE: 


Reason: 


Action: 


228 *R*¥ 
DEFINED 
ECODE: 


Reason: 


Action: 


229 *R* 
DEFINED 
ECODE: 


Reason: 


Action: 
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PLAN WORD NOT REAL °@ 


A subscript indicating the com 
munication array location that 
was found to be TRUE or FALSE. 
A word required to be real is 
TRUE or FALSE. 

Level error recovery and 
ping is initiated. 


skip- 


PLAN WORD NOT TRUE 


A subscript indicating the com- 
munication array location that 
was found to be FALSE or REAL. 
A word required to be TRUE is 
FALSE or REAL. 

Level error recovery and 
ping is initiated. 


skip- 


PLAN WORD NOT FALSE e 


A subscript representing the 
communication array that is 
found to be TRUE or REAL. 
A word required to be FALSE is 
found to be TRUE or REAL. 


Level error recovery and skip- 
ping is initiated. 
UNDEFINED SYMBOL IN INPUT 


A cursor pointing to the end of 
the symbol in question. 


A symbolic data name has been 


misspelled, or a comma was 
omitted after the command in a 
statement. No symbol table 


entry can be found for the word 


in this statement or in any 
statement upon which this 
statement is depencient. 


Failure to terminate a command 
with a semicolon results in the 
next command being interpreted 
as data for the command that 
precedes it. 

The command is not executed, 
but the scan is completed. 


UNDEFINED SYMBOL IN EXECUTION- 
SYMBOL EXPRESSION e 


The sequence number of the 
expression in the phrase 
definition. 

A symbolic subscript expression 
contains an undefined symbol. 
The scan is completed and_ the 


level error recovery is 
initiated. 
UNDEFINED SYMBOL IN PHRASE- 


EXPRESSION e 


The sequence number of the 


expression in the phrase 
definition. 
A symbol used in a phrase- 


defined expression is found to 
be undefined. 
The scan is completed and the 
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level error 
initiated. 


recovery is 


e 230 *R* OVER 8 VERBS IN INPUT STATEMENT e 


ECODE: A pointer to the end of the 
ninth verb. 

Reason: A command may not contain more 
than eight verb phrases and an 
object phrase. 

Action: Statement scan is terminated. 


231 *R* DITTO WORD IN COMMON NOT ALPHA e 


ECODE: A pointer to the communication 
array word that is to be sub- 
stituted in a command for a 
ditto mark. 

Reason: Using the ditto character in a 


command depends on the defini- 
tion of the preceding command. 
The word that is to be substi- 
tuted is not alphabetic. 

Action: The scan is terminated and 
level error recovery is 
initiated. 


232 *R* EXECUTION-DEFINED 
SCRIPT NOT POSITIVE e 


SYMBOL SUB- 


ECODE: The sequence of the subscript 
expression within the phrase 
definition. 

Reason: Evaluation of a symbolic. sub- 
script within the phrase 
definition has yielded a nega- 
tive or zero result indicating 
an invalid communication array 
location. 

Action: The scan is completed and level 


error recovery is initiated. 


233 *R* EXECUTION-DEFINED SYMBOL SUB- 
SCRIPT GREATER THAN 8176 OR 511 WITH 


P-VALUE @ 

ECODE: A number indicating the 
sequence of the symbolic sub- 
script in the phrase 
definition. 

Reason: The symbolic subscript expres- 
sion, when evaluated, is found 
to be too large. 

Action: The scan is completed and the 


level error 
initiated. 


recovery is 


234 =*R* INSUFFICIENT ROOM IN 
ARRAY SAVE FILE e 

ECODE: Number of additional words 
needed in PDATA file. 

The file specified for saving 
the managed communication array 
is too small to allow saving of 
the context of the current 
managed array. 

The scan is completed and the 
level error recovery is 
initiated. 


MANAGED 


Reasons 


Action: 


235 *R* MANAGED ARRAY DEFINITION TOO 
LARGE ®@ 
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ECODE: The number of words in excess 
of the allowable size. 
Reason: A communication array has been 


specified that cannot be accom- 
modated by the current 
partition/machine size. 

Action: The array is not saved or 
restored by PLAN data manage- 
ment, and the array is not 
initialized to FALSE at level 1 
phrase time. 


236 *R* INITIALIZATION 
OUTSIDE OF COMMON e 


VALUE SUBSCRIPT 


ECODE: Value of subscript. 

Reason: The CAP index for a default 
value is outside the current 
communication array. 

Action: The value is not stored. 


237 *R* DATA PLACEMENT FROM INPUT STREAM 
OUTSIDE OF COMMON e« 


ECODE: Input cursor. 

Reason: The CAP index of an input value 
is outside the current communi- 
cation array specification. 

Action: The value is not written to the 


communication array. 


239 *R* DATA PLACEMENT FROM PHRASE- 
DEFINED EXPRESSION OUTSIDE OF COMMON e 


ECODE: Expression. number. 

Reason: The CAP index for storage of 
the results of an expression 
evaluation is outside the cur- 
rent communication array 
specification. 

Action: The value is not written to the 


communication array. 


240 *R* FIRST CHARACTER IN INPUT STREAM 


AFTER PHRASE NOT COMMA, COLON, OR 
SEMICOLON e 
ECODE: A cursor to the unexpected 


character. 
Reason: The character required to 
start/terminate data collection 
was not encountered. 
The scan is completed and the 
level error recovery is 
initiated. 


Actions: 


241 *R* UNRECOGNIZABLE CHARACTER IN INPUT 


STREAM e 

ECODE: A cursor to the unrecognizable 
character. 

Reason: A character cannot be interro- 
gated in this context. It may 
have resulted from an illegal 
multipunch. 

Action: The scan is completed and the 
level error recovery is 
initiated. 


242 *R* SEMICOLON IN LITERAL OR EMPTY 
LITERAL ¢ 
ECODE: A cursor pointing to the inval- 


id semicolon. 
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Reason: Either the literal closure 
character is missing or a semi- 
colon is present within the 
literal. 

Action: The scan is completed and level 
error recovery is initiated. 


243 *R* NUMBER OUTSIDE ALLOWABLE 
FLOATING-POINT RANGE e 
ECODE: A cursor to the end of the 


offending constant. 

Reason: A number larger than can be 
contained in a floating-point 
number has been encountered. 
Note that the limit is 
-17014117E39 on the 1130. 

Action: The scan is completed and level 
error recovery is initiated. 


244 *R* IMPLIED DO NOT FOLLOWED BY SINGLE 
VALUED CONSTANT ® 


ECODE: A pointer to the position proc- 
essed when the error was 
detected. 


Reason: A single logical or numeric 
value does not follow an 
implied DO definition. 

Action: The scan is completed and level 
error recovery is initiated. 


245 *R* OVER 1000 EXPRESSION GO-TO'S 

EXECUTED e 

ECODE: A number indicating the 
sequence of the expression 
found to be in error or input 
cursor. 

Reason: Only 1000 formula GO-TO'S are 
allowed within any phrase. 
This limit has been exceeded. 

Action: The scan is completed and level 
error recovery is initiated. 


246 *R* CHECK-ENTRY SUBSCRIPT OUTSIDE OF 

COMMON e 

ECODE: Subscript value. 

Action: The indicated communication 
array location is not checked. 

Reason: The CAP index requiring execu- 
tion of a check is outside the 
current communication array 
specification. 


247 *R* DATA RETRIEVAL OUTSIDE OF COMMON 

Program: PSCAN 

ECODE: A cursor to the input stream 
subscript. 

Reason: An attempt has been made to 
access data outside the current 
communication array. 

Action::. A 1.0 is supplied for arithmet- 
ic calculations and 0.0 for 
relational calculations. The 
scan is completed and level 
recovery is initiated. 


248 *R* DATA RETRIEVAL OUTSIDE OF COMMON 
IN EXECUTION-DEFINED SYMBOL EXPRESSION e 
ECODE: The expression number. 
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Reason: 


Action: 


249 *R* 
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An attempt has been made to 
access data outside the current 
communication array. 

A 1.0 is supplied for arithmet- 
ic calculations and 0.0 for 
relational calculations. The 
scan is completed and level 
recovery is initiated. 


DATA RETRIEVAL OUTSIDE OF COMMON 


IN PHRASE-DEFINED EXPRESSION « 


ECODE: 
Reason: 


255 ¥*R*t 


The expression number. 

An attempt has been made to 
access data from a location out- 
side the current communication 
array specification. 

A 1.0 is supplied for arithmetic 
calculations and 0.0 for rela- 
tional calculations. The scan is 
completed and level recovery 
initiated. 


STATEMENT SAVE INVALID, PHRASE 


PUSHED FROM CHECK-ENTRY ® 


ECODE: 
Reason: 


Action: 


263 *R* 


CAP location being checked. 
Implicit statement saving may 
not be combined with check 
entry pushed phrases. 

The statement is not saved; the 
PLAN error recovery is 
initiated, but the phrase is 
pushed. 


INVALID FORMAT IN INPUT STREAM 


EXPRESSION e 


ECODE: 


Reason: 


Action: 


264 *R* 
DEFINED 
ECODE: 


Reason: 


A cursor to the offending 

position. 

An input stream expression is 

found to contain improper syn- 

tax. Reasons for this diag- 
nostic may be: 

a. Arithmetic operators without 
an intervening constant or 
data name. 

b. An arithmetic or logical 
operator immediately follow- 
ing a parenthesis. 

c. An arithmetic or logical 
operator immediately fol- 
lowed by a right 
parenthesis. 

d. Invalid characters. 

The scan is completed and level 

error recovery is initiated. 


INVALID FORMAT IN EXECUT ION- 
SYMBOL EXPRESSION e 
A number indicating the 
sequence of the expression in 
error. 
A syntax error has been 
detected in the symbolic. sub- 
script defined at ADD PHRASE 
time. Reasons for this diag- 
nostic may be: 
a. Arithmetic operators without 
an intervening constant or 
data name. 
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b. An arithmetic or logical 
operator immediately follow- 
ing a parenthesis. 

c. An arithmetic or logical 
operator immediately fol- 
lowed by a right 
parenthesis. 

d. Invalid characters. 

The scan is completed and level 

error recovery is initiated. 


Action: 


265 *R* INVALID FORMAT IN PHRASE-DEFINED 

EXPRESSION e@ 

ECODE: A number indicating the 
sequence of the expression in 
error. 

Reason: A syntax error has been 

detected in the phrase defini- 

tion of an expression. Reasons 
for this diagnostic may be: 

a. Arithmetic operators without 
an intervening constant or 
data name. 

b. An arithmetic or logical 
operator immediately follow- 
ing a parenthesis. 

c. An arithmetic or logical 
operator immediately fol- 
lowed by a right 
parenthesis. 

d. Invalid characters. 

The scan is completed and level 

error recovery is initiated. 


Actions: 


266 *R* BCD LEFT PARENTHESIS USED IN 

INPUT STREAM LOGICAL EXPRESSION e 

ECODE: A pointer to the erroneous 
parenthesis. 


Reason: All logical expressions must be 
punched in EBCDIC code. 
Action: The scan is completed and level 


error recovery is initiated. 


268 *R* BCD LEFT PARENTHESIS USED IN 

PHRASE-DEFINED LOGICAL EXPRESSION e 

ECODE: A number indicating the 
sequence number of the expres- 
sion in error. 


Reason: Logical expressions must be 
punched in EBCDIC code. 
Action: The scan is completed and level 


error recovery is initiated. 


269 *R INPUT STREAM EXPRESSION TOO COM- 
PLICATED TO BE ANALYZED e 


ECODE: A pointer to the position at 
which error was detected. 

Reason: Too many levels of parenthesis 
have been encountered. 

Action: The scan is completed and level 


error recovery is initiated. 


270 *R* EXECUTION-DEFINED SYMBOL EXPRES- 

SION TOO COMPLICATED TO BE ANALYZED e 

ECODE: A number indicating the 
sequence of the expression 
found to be in error. 


Reasons Too many levels of parenthesis 
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have been encountered. 
The scan is completed and level 
error recovery is initiated. 


Action: 


271 *R* PHRASE-DEFINED EXPRESSION TOO 

COMPLICATED TO BE ANALYZED e 

ECODE: A number indicating the 
sequence of the expression 
found to be in error. 


Reason: Too many levels of parenthesis 
have been encountered. 
Action: The scan is completed and level 


error recovery is initiated. 


272 *R* INVALID FORMAT IN INPUT STREAM 
LITERAL RELATIONAL EXPRESSION e 


ECODE: A pointer to the character 
processed when the error was 
discovered. 

Reason: A syntax error in an alphabetic 
relational expression. This 
diagnostic may result from 
expressions of the nature: 

a. 5="A" 
b. A>“B" 
c. B<"*C*" 
Action: The scan is completed and level 


error recovery is initiated. 


274 *R* INVALID FORMAT IN PHRASE-DEFINED 

LITERAL RELATIONAL EXPRESSION e 

ECODE: A number indicating the 
sequence of the expression 
causing the error. 


Reason: A syntax error in a phrase- 
defined relational. This diag- 
nostic may result from expres- 
sions of the nature: 

a. 5="A*" 
b. A>"“B" 
c. B<*C" 
Action: The scan is completed and level 


error recovery is initiated. 


275 *R* INVALID FORMAT IN INPUT STREAM 

SUBSCRIPT EXPRESSION e 

ECODE: A pointer to the character 

processed when error was 

detected. 

A syntax error in a_= symbolic 

subscript or a subscript 

expression evaluation yields a 

negative result. Reasons for 

this diagnostic may be: 

a. Result of subscript expres- 
Sion is not positive. 

b. A logical value was encoun- 
tered during the evaluation 

c. An Implied Do was’ encoun- 
tered in the evaluation of a 
subscript expression. 

The scan is completed and level 

error recovery is initiated. 


Reason: 


Action: 


276 *R* INVALID FORMAT | IN EXECUTION- 

DEFINED SYMBOL SUBSCRIPT EXPRESSION e 

ECODE: A pointer to the character 
processed when the error was 


DIAGNOSTICS (13.0.0) 159 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


detected. 
Reason: A syntax error in 
expression. 
The scan is completed and level 
error recovery is initiated. 


symbol 


Action: 


277 *R* INVALID FORMAT IN PHRASE-DEFINED 
SUBSCRIPT EXPRESSION e 

ECODE: A number indicating the 
sequence of the expression 
found to be in error. 

A syntax error. 

The scan is completed and level 
error recovery is initiated. 


Reason: 
Action: 


278 *R* UNBALANCED PARENTHESES IN INPUT 
STREAM EXPRESSION e 


ECODE: A pointer to the position at 
which the error was detected. 

Reason: An unequal number of right and 
left parentheses are found in 
an expression. 

Action: The scan is completed and level 


error recovery is initiated. 


279 *R* UNBALANCED PARENTHESES IN 
EXECUTION-DEFINED SYMBOL EXPRESSION e 


ECODE: A pointer to the position at 
which the error was detected. 

Reason: An unequal number of left and 
right parentheses are found in 
an expression. 

Action: The scan is completed and level 


error recovery is initiated. 


280 *R* UNBALANCED PARENTHESES IN PHRASE- 
DEFINED EXPRESSION e 

ECODE: A number indicating the 
sequence of the expression 
found to be in error. 

An unequal number of left and 
right parentheses have been 
found, or a right parenthesis 
has been found with no preced- 
ing matched left parenthesis. 
The scan is completed and level 
error recovery is initiated. 


Reason: 


Action: 


281 *R* INVALID FORMAT IN INPUT STREAM 

CONDITIONAL EXPRESSION e 

ECODE: A pointer to the position at 

which the error was detected. 

A syntax error. Reasons for 

this diagnostic may be: 

a? or ! not followed by #, 
=, :, or § 

The scan is completed and level 

error recovery is initiated. 


Reasons: 


Action: 


283 *R* INVALID FORMAT IN PHRASE-DEFINED 

CONDITIONAL EXPRESSION e 

ECODE: A number indicating the 
sequence of the expression 
found to be in error. 

Reason: A syntax error. Reasons for 
this diagnostic may be: 
a ? or ! not followed by #, 

=, 3, or § 
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Action: The scan is completed and level 


error recovery is initiated. 


284 *R* INVALID FORMAT IN INPUT STREAM 
RELATIONAL EXPRESSION e 

ECODE: A pointer to the position at 
which the error was detected. 

A snytax error. Reasons for 
this diagnostic may be: 

a. Unbalanced parenthesis 

b. Invalid characters 

The scan is completed and level 
error revovery is initiated. 


Reason: 


Action: 


286 *R* INVALID FORMAT IN PHRASE-DEFINED 
RELATIONAL EXPRESSION ¢ 


ECODE: A number giving the sequence of 
the expression found to be in 
error. 

Reason: A syntax error. Reasons for 
this diagnostic may be: 

a. Unbalanced parenthesis 
b. Invalid characters 
Action: The scan is completed and level 


error recovery is initiated. 


287 *R* INVALID END TO AN INPUT STREAM 
EXPRESSION e¢ 


ECODE: Input cursor. 

Reason: An expression must end with a 
semicolon or comma. 

Action: The scan is completed and level 


error recovery is initiated. 


289 *R* INVALID END TO A PHRASE-DEFINED 
EXPRESSION e 


ECODE: Sequence number of the expres- 
sion in error. 

Reason: An expression must end with a 
semicolon or comma. 

Action: The scan is completed and level 


error recovery is initiated. 


290 *R* LOGICAL EOF ENCOUNTERED IN PSCAN 


INPUT e 

ECODE: Undefined. 

Reason: A logical EOF has been set by a 
PSCAN CALL PLINP operation. 

Action: The scan is completed and level 


error recovery is initiated. 


291 *R* INVALID END OF PLAN JOB e 


ECODE: Undefined. 

Reason: (1130 only) A monitor control 
record has been processed. The 
record will not be processed by 
1130 monitor. 

Action: Monitor continues processing at 


the next record. 


299 FR OF C# KHEEEEKEREREKEEREEEEE © 


ECODE: A pointer to the communication 
array upon which an unsuccess- 
ful test was made. 

Reason: The text for this diagnostic is 


normally user-defined text from 
a phrase-defined check entry. 
If the asterisks are provided, 
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an error has been detected in 
the defined literal. 


Action: The phrase is terminated. 


13.9.0 1130 ONLY DIAGNOSTICS 


The following messages are generated from 
1130 PLAN during the initialization phase. 


e 700 *C* PFILE FOUND ON PACK xxxx e 


Program: PLAN 

ECODE: None produced. 

Reasons This message is produced every 
time that PLAN is executed; it 
lists the cartridge identifica- 
tion of the pack on which the 
language dictionary was found. 

Action: Processing continues. 


© 701 *E* XXXXX NOT FOUND IN LET OR FLET e¢ 
Program: PLAN 
Reason: XXXXX (which may be PSCAN, 
PERRS, PFILE, or PDQZ0) is not 
in the library. 


e 702 *E* PFILE IS TOO SMALL e 


Program: PLAN 

Reason: The PLAN dictionary is too 
small. It must contain a mini- 
mum of 17 sectors on 1130 PLAN 
or 14 sectors on OS or DOS 
PLAN. 

Action: PLAN execution is inhibited. 


e 703 *C* PFILE INITIALIZED ON PACK XXXX e 


Program: PLAN 

Reason: The PLAN dictionary was found 
to be uninitialized and has 
been initialized. 

Action: Normal processing continues. 


© 725 *O* MOUNT PACK xxxx ON LOG DR ne PHY 

DR 0,1,2,3,4 @ 

Reason: A request has been made for a 
disk cartridge that is not 
available. (See “Pack Changing 
Procedures" under “DYNAMIC File 


Support", 8.6.0.) 
e 799 *E* PLAN EXECUTION INHIBITED e 
Program: PLAN 
Reason: Given after message 702 or when 
PSCAN, PERRS, PFILE or PDQZ0O 
are not in LET/FLET. 
Action: PLAN execution is inhibited. 


13.10.0 DOS ONLY DIAGNOSTICS 


The following messages are produced by DOS 
PLAN. 
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e 820 *E* DFJPFIL MISSING OR FORMATTED 
INCORRECTLY «¢ 
Reason: Language file is incorrectly 
defined. 
Action: PLAN execution is inhibited. 


e 821 *E* XXXXXXXX NOT FOUND IN CORE IMAGE 
LIBRARY e 


Reason: DFJPSCAN, DFJPHRAS, or DFJPERRS 
not found in program library. 
Action: PLAN execution is inhibited. 


e 822 *E* XXXXXXXX IS AN INVALID PLAN RUN 
CONTROL CARD ¢ 


Reason: The xxxxxxxx field represents 
the first eight characters of 
the invalid control card. 

Action: PLAN execution is inhibited. 

e 890 *R* UNCORRECTABLE INPUT/OUTPUT 

ERROR ¢ 

Program: Last entered. 

ECODE: DOS logical unit. 

Action: Current statement execution is 


aborted and level error recov- 
ery is invoked. 


e 899 *E* PLAN EXECUTION INHIBITED e 


Reason: Provided by the preceding 
diagnostic. 
Action: PLAN execution is inhibited. 


13.11.0 OS ONLY DIAGNOSTICS 


The following messages are generated from 
the DD card edit performed by OS/360 PLAN. 
The message form is DDNAME, TEXT. 


e 901 *E* XXXXXXXX NOT FOUND IN THE PLANLIB 
PDS e 


Program: PLAN 

Reason: The named module could not be 
loaded by the PLAN system. The 
modules are DFJPERRS, DFJPSCAN, 
or DFJRETN. 

Action: PLAN execution is inhibited. 


e 902 *E* DDNAME, DOES NOT SPECIFY A DIRECT 
ACCESS DEVICE e 


Program: PLAN 

Reason: The unit parameter of the spec- 
ified DD card is incorrect. 

Action: PLAN execution is inhibited. 

e 903 *E* DDNAME, DATA SET DOES NOT EXIST e 

Program: PLAN 

Reasons The data set named in the DD 
card does not exist on the 
specified volume. 

Action: PLAN execution is inhibited. 


e 904 *E* DDNAME, INVALID BLKSIZE 


SPECIFICATION e 
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Program: PLAN 

Reason: The specified BLKSIZE parameter 
is either too large for the 
unit specified or not a mul- 
tiple of LRECL. 

Action: PLAN execution is inhibited. 


e 905 *E* DDNAME, 
SPECIFICATIONS e 


INVALID DSCB 


Program: PLAN 

Reason: The data set named in the spec- 
ified DD card: 
a. Has a partitioned data set 

format 

b. Has RECFM other than F or FB 
c. contains keys 
d. was never closed 

Action: PLAN execution is inhibited. 

e 906 *E* DDNAME, INVALID SPACE 

ALLOCATION »® 

Program: PLAN 

Reason: The space parameter in the 
named DD card does not specify 
TRK or CYL allocations. 

Action: PLAN execution is inhibited. 

e 907 *E* DDNAME, T/0 ERROR WHILE 

FORMATTING e 

Program: PLAN 

Reason: Input/Output error. 

Action: PLAN execution is inhibited. 


e 908 *E* DDNAME, IS AN INVALID PLAN DD 


CARD e 
Program: PLAN 
Reason: The numeric specification on a 
PLINPxxx, PLOUTxxx, PLANFILx, 
or PLFSxxxx DD card is invalid. 
Action: PLAN execution is inhibited. 


© 909 *E* DDNAME, DATA SET INITIALIZED 


INCORRECTLY e 


Program: PLAN 

Reason: A PLANFILX, PLSYSTAB, or PLNUM- 
TAB was specified with DISP= 
OLD, and is not formatted 
correctly. 

Action: PLAN execution is inhibited. 


e 910 #E* DDNAME, INSUFFICIENT FILE SIZE e 


Program: PLAN 

Reason: PLSYSTAB or PLANFILX is not 
allocated sufficient space for 
correct execution. 

Action: PLAN excution is inhibited. 


© 911 *E* DDNAME, NOT DEFINED IN A_ DD 


CARD e 
Program: PLAN 
Reasons: PLANFILO, PLSYSTAB, or PLANLIB 
DD cards are missing. 
Action: PLAN execution is inhibited. 
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The following messages are generated from 
OS/360 PLAN during the initialization 
phase. 


© 922 *E* XXXXXXX PARAMETER OR OPERAND IS 
INVALID ¢ 


Program: PLAN 

Reason: The named parameter in the EXEC 
control card is invalid. 

Action: PLAN execution is inhibited. 


@® 940 *R* DDNAME I/O ERROR e 
Program: Current program in control. 
Action: Phrase abort. 


@ 941 *R* XXXXXXXXXXXXXXXX © 


Program: Current program in control. 

Reason: A program interrupt occurred in 
a problem program. The diag- 
nostic message is the program 
interrupt. 

Action: PLAN level error recovery is 
initiated. 


e 942 *R* INSUFFICIENT 
PLAN FUNCTION e 


PROGRAM AREA FOR 


Program: PLAN 

Reason: The area allocated for the pro- 
gram area is too small. 

Action: Phrase abort. 


e® 999 *E* PLAN EXECUTION INHIBITED e 


Program: PLAN 

Reason: This action results if any of 
the above 900-series error con- 
ditions listed occur. 

Action: PLAN execution is inhibited. 


PLAN will ABEND during PLAN initialization 
with the following user codes: 


e ABEND USER CODE 100 e 


Program: PLAN 

Reason: Missing or invalid PLINP/PLOUT 
DD card. 

Action: PLAN execution is inhibited. 


e ABEND USER CODE 101 e 


Program: PLAN 

Reason: Unable to load one of the fol- 
lowing PLAN modules: DFJLODER, 
DFJ TRACE 

Action: PLAN execution is inhibited. 


® ABEND USER CODE 102 e 


Program: PLAN 
Reason: No DD card supplied. 
Action: PLAN execution is inhibited. 


® ABEND USER CODE 103 e 


Program: PLAN 

Reason: Insufficient core storage to 
initialize PLAN. 

Action: PLAN execution is inhibited. 
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14.0.0 APPENDIX G: 


The main body of this manual defines a 
specification for a PLAN system that 
operates compatibly across the 1130, DOS, 
and OS versions (except as specifically 
noted). Special support provided in each 
of these systems is detailed in Appendices 
A, B and C. 


Compatibility across all three versions of 
PLAN is provided as long as the compatible 
PLAN specifications are adhered to and as 
long as program modules are written in a 
language for which a compiler is provided 
on- all three monitor/operating systems. 
The only language meeting such a require- 
ment is ASA BASIC FORTRAN IV. Statements 
included in BASIC FORTRAN are detailed 
below: 


ASSIGNMENT STATEMENTS 
Variable = arithmetic expression 


FORMAT STATEMENT 


Statement-number FORMAT (format- 
specification) 
(Note: Because of difference in parame- 


ter specification, care should be exer- 
cised here if compatibility is required. 
PLAN Sequential I/O should be examined 
here for this type of support.) 


CONTROL STATEMENTS 

CALL 
{ (argument [{,argument]...)] 
CONTINUE 
DO statement-number control-variable 
initial-value, test-value [, increment] 
END 
GO TO statement-number 
GO TO (statement-number, statement-number 
[,statement-number]...) variable 
IF (arithmetic—expresion) 
number, 
statement-number 
PAUSE fone-to-four decimal digits] 
RETURN 
STOP [fone-to-four decimal digits] 

(Note: The appendices contain specific 


statement- 
statement-number, 


subroutine-name 
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restrictions on the use of the STOP 
statement.) 
READ (data-set-number, format-statement-— 
number) [list] 
(Note: See comment under FORMAT and 
special comment in Appendix A.) 
WRITE (data-set-number, format-statement- 
number) {list] 
(Note: See comment under READ.) 
DEFINE FILE data-set-number (number-of 
records, maximum-record-size, U, 
associated-variable) 
{data-set-number..]... 
(Note: See comment under READ.) 
FIND (data-set-number' relative-position) 
(Note: See comment under READ.) 
READ (data-set-number’ relative-position) 
[list] 


(Note: See comment above under READ.) 
WRITE (data-set-number'" relative- 
position) [list] 


SPECIFICATION STATEMENTS 
COMMON name [,name] 


COMMON array-declarator 
[,array~declarator] 

DIMENSION array-declarator 
(,array-declarator] 
EQUIVALENCE (name [,name]}...) 
[(name[,name]...)]... 

EXTERNAL subprogram-name 


{, subprogram-name] 
INTEGER name [,name] 
REAL name [,name] 


SUBPROGRAM STATEMENTS 
FUNCTION function-name 
{,argument ] ) 
function-name (argument 
arithmetic-expression 
INTEGER FUNCTION function-name 
REAL FUNCTION function-name 
SUBROUTINE subprogram- name 
[,argument]...)] 


(argument 


{,argument]...)= 


(Cargument 


CONSTANT AND VARIABLE TYPES 
INTEGER 
REAL 


COMPATIBILITY (14.0.0) 163 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


15.0.0 APPENDIX H: 


This appendix provides a summary of limits 
and restrictions defined throughout this 


manual. The material is duplicated here 
merely as a convenient reference for the 
reader. 


1. Maximum number of names in pop-up list: 
50 


2. Maximum PLAN statement length: 


450 characters including semicolon 
(excluding all leading blanks) 

3. Maximum number of symbols in an ADD 
PHRASE: 
255 


4. Allowable formula numbers: 


a. ADD PHRASE: 0-1024 
b. Input stream 0-32, 767 


5. Maximum formula execution branches: 
1000 


6. Maximum communication array size 
a. 32,767 except on 


(1) 8K 1130 with 8K PSCAN/PERRS: 
910 

(2) 16K 1130 with 8K PSCAN/PERRS: 
4606 

(3) 32K 1130 with 8K PSCAN/PERRS: 
12,798 

(4) 16K 1130 with 16K PSCAN/PERRS: 
1024 

(5) 32K 1130 with 16K PSCAN/PERRS: 
9216 
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Maximum recognized alphabetic charac- 
ters in word: 

3 

Maximum words in a phrase: 

5 

Maximum phrases in a statement: 

45 words = 1 object phrase + 8 verb 


phrases 


Maximum CAP index in ADD PHRASE: 
16,368 


Maximum CAP value resulting from eval- 
uation of ADD PHRASE expression: 

a. 8176 

b. 512 if a scale factor is defined 


Maximum range of Implied Do: 


65,368 

Maximum CAP index for implicit check 
entry literal: 

16,384 

Maximum DYNAMIC/ PERMANENT logical 
drives: 


a. 5 on 1130 
b. 8 on OS/DOS 


Allowable DYNAMIC/PERMANENT file num- 
bers per logical drive: 1-255 
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16.0.0 APPENDIX I: PLAN CHARACTER SET 


The following chart defines the characters $ ,;-~------~-7------~--7-----------7------- 1 
that are required for PLAN language defini- | CHARACTER | CARD CODE | HEXADECIMAL | DECIMAL | 


tion. Characters not shown in this. chart }--------- 4--------- 4-----~---———- 4+------~— 4 
may be entered as a character within liter- | A | 12-1 | ci {| 193 | 
al text. | B { 12-2 | C2 {| 194 | 

| Cc | 12-3 | c3 {| 195 | 

| D { 12-4 | c4 | 196 | 

| E | 12-5 | c5 | 197 | 

| F | 12-6 | C6 { 198 | 

| G {| 12-7 | C7 | 199 | 
(77-1 7 ----- —————4 | H | 12-8 | c8 | 200 | 
| CHARACTER | CARD CODE| HEXADECIMAL | DECIMAL| { I | 12-9 { c9 } 201 | 
}----------+4--~--- —~-+----------- 4-------- 4 | J {| 11-1 | D1 { 209 | 
| blank | { 40 | 64 | | K { 11-2 | D2 { 210 | 
| * { 12-8-3 | 4B { 75 | | L | 11-3 | D3 | 211 | 
| < {| 12-8-4 | KC | 76 | | M | 11- | D4& {| 212 | 
| ( {| 12-8-5 | &D | 77 | | N | 11-5 | D5 {| 213 | 
| + | 12-8-6 | 4E | 78 | | Oo | 11-6 | D6 {| 214 | 
{ | | 12-8-7 | uF { 79 | | P | 11-7 | D7 {| 215 | 
| & } 12 | 50 1 80 | | Q {| 11-8 | D8 { 216 | 
| ! {| 11-8-2 | 5A | 90 | | R { 11-9 | D9 {| 217 | 
| $ { 11-8-3 | 5B { 91 | | S {| 0-2 | E2 { 226 | 
{ * | 11-8-4 | 5C | 92 | | T | 0-3 | E3 | 227 | 
{ ) { 11-8-5 | 5D { 93 { | U | oO-4 | E4 | 228 | 
| ; | 11-8-6 | 5E 1 94 | | Vv | oO-5 | E5 { 229 | 
| 1 { 11-8-7 | SF } 95 | { W | 0-6 | E6 { 230 | 
| ~ } 11 | 60 { 96 | | X | 0-7 | E7 | 231 | 
| / } O-1 { 61 | 97 | | Y | 0o-8 | E8 { 232 | 
| é | 0-8-3 | 6B | 107 | | Z {| 0-9 | E9 { 233 | 
{ % { o-8-4 | 6C {| 108 | | 0 | oO | FO | 240 | 
| — | 0-8-5 | 6D {| 109 | | 1 | 1 | F1 | 241 | 
| > | 0-8-6 | 6E { 110 | | 2 | 2 | F2 { 242 | 
{ ? { 0-8-7 | 6F { 111 | | 3 | 3 | F3 | 243 | 
| : | 8-2 {| 7A } 122 | | 4 | 4 {|  ¥F4 { 244 | 
| # | 8-3 | 7B | 123 | | 5 1 5 | F5 |} 245 | 
| a {| 8-4 | 7c | 1246 | | 6 { 6 | F6 | 246 | 
| ‘ {| 8-5 | 7D | 125 | | 7 | 7 | F7 {| 247 | 
| = | 8-6 | TE | 126 | | 8 | 8 | F8 { 248 | 
| ig | 8-7 | TF | 127 | | 9 | 9 | F9 { 249 | 
ee eeeaehne ieee ene een ae ee ere ere J are een Pee Reeomee aan a eseeer seepage een i eae re oe J 


CHARACTER SET (16.0.0) 165 


IBM PROBLEM LANGUAGE ANALYZER (PLAN) 


PROGRAM DESCRIPTION MANUAL 


17.0.0 APPENDIX J: SYSTEM REQUIREMENTS 


MACHINE CONFIGURATIONS 
IBM 1130 PLAN 


Minimum requirement for PLAN operation 
1131 Central Processing Unit Model 2B 


2501 Card Reader Model Ai or A2 
#3630 (1130/2501 Coupling) 
#8042 Attachment 
#3054 Expansion Adapter 

AND 

1442 Card Punch Model 5 

#4449 Attachment 


OR 


1442 Card Read Punch Model 6 or 7 
#4454 Attachment 


Optional Support 
1131 Central Processing Unit Models 2C, 
2D, 3B, 3C, or 3D 


1132 Printer 
#3616 
#3854 Expansion Adapter 


1403 Printer Model 6 or 7 
#4424 or #4425 Attachment 
#1865 Channel Multiplexor 


2310 Disk Storage Model B1 or B2 (one or 


two) 
#3201, #3202, #3203, #3204 disk 
control 

1133 Multiplex Control Enclosure 
(required for 1403 or 2310) 
#1865 Multiplexor 
#7490 Storage Access Channel 

SYSTEM/360 DOS PLAN 
Central Processing Unit 
2025, 2030, 2040, 2050, 2065, or 2075 


(32K bytes or larger). 
sor is assumed.) 
Floating-Point Arithmetic 
One I/O Channel (either multiplexor or 
selector) 
One Card Reader 
2540) 
(one 


(An 8K supervi- 


(1442, 2501, 2520, or 


2400 series tape drive may be 
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substituted) 

One Card Read Punch (1442, 2520, or 2540) 
(one 2400 series tape drive may be 
substituted) 


One Printer (1403, 1404, 1443) 
(one 2400 series tape drive may be 
substituted) 

One 1052 Printer-Keyboard 

One 2311 Disk Storage Drive 

One 2841 Storage Control 


SYSTEM/360 OS PLAN 


Central Processing Unit 
2030, 2040, 2050, 2065, or 2075 that 
provides a problem partition of 32K 
bytes or larger for PCP-MFT and a 
region of 44K bytes or larger for MVT 
Floating-Point Arithmetic 
One Console 
Any direct access device and control unit 
supported by 0OS/360 with a storage capac- 
ity equal to or greater than one 2311 
Disk Storage Drive (in addition to that 
required by System/360) 
One or more input devices supported by 
QSAM 
One or more output devices 
QSAM 


Supported by 


ALL VERSIONS OF PLAN 


The availability of an 029 printing key- 
punch will prove to be an asset in the 
preparation of PLAN language statements. 


PROGRAMMING SYSTEM REQUIREMENTS 


PLAN operates under three IBM monitor or 
operating systems. It is written primarily 
in Assembly Language. Some Utility func- 
tions are programmed in BASIC FORTRAN IV. 


IBM 1130 PLAN operates under the 1130 Disk 
Monitor System, Version 2. 


System/360 DOS PLAN operates under the IBM 
System/360 Disk Operating System. 


System/360 OS PLAN operates under the IBM 
Operating System/360 using the MVT, PCF, or 
MFT options. 
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18.0.0 APPENDIX K: 


The charts in this section represent the 


hierarchial structure of the PLAN system 
components. The first charts represent the 
functional areas and the subfunctional 


areas as described in the systems overview. 
Subsequent charts define the system com- 
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ponents within the functional areas. The 
number on the lower line of the program 
component blocks define the major section 
where the function and use of the component 
is described. 
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Sanne caaneneentermmnnenne 1 
| PROBLEM 
| LANGUAGE 
| ANALYZER 
| (PLAN) [ 
|OS-DOS/360, 1130] 
Ge eee aia J 
1 
[mtn nnn 5 SECEERAnetnninenennnnenetemmnted 1 : cnn inne 1 
| | I | 
[—------ bem —. oC A mee 1 pceorto oo 5 al canenennens 4—--————= Vorccco 4----——— 1 
| DYNAMIC | |USER- {| | 1 | | 
| JOB { | ORIENTED | |DIAGNOSTIC | | INPUT/ | | AUXILLIARY l 
| SUPERVISION &| | LANGUAGE 1 | { | OUTPUT i | 
SEQUENCING | | PROCESSING {| | SUPERVISION | | CONTROL | | FUNCTIONS l 
| 1 | 1 | 1 | I | | 
bleseSetintas ey I eee neers eee es se eee ee i ee ne eee Ep Serre nee timr erent: J 
{ | | | | 
| eo -— | -----------— 4.) === ——y | ¢------------- a0 econ 
| ti 11] It i | | STANDARD | 
i | Itt 13] lit | | | PLAN | 
| { EXECUTION | | | LANGUAGE | | | DIAGNOSTIC |] {| SEQUENTIAL | | | COMMANDS & | 
t-1 1 t-4 | }+-4 GENERATOR & | }-4 FILE 1 +-4 SUPPORTING | 
1 1 SUPERVISOR | | | COMPILER 1] CONTROLLER | | | SUBROUTINES| | | MODULES 
| | SEE TREE 2 { | | SEE TREE 4 | | |SEE TREE 6 1] | SEE TREE 7 | | | SEE TREE 10 | 
fae ees Sif Reese ee e OW) Cieese ao $f a teeter 
| | | | | 
| pctron noe —4 | e¢------------- . 01 e-------- a0. e-ccereo oo - qo. ecco 1 
I | iff | | {USER itl | | [ARRAY | 
| | EXECUTION {| | [LANGUAGE { | | DIAGNOSTIC | | | PERMANENT | | | & TABLE | 
tJ SEQUENCE J} te { t-4 INPUT | t-i FILE | $-4 PROCESSOR i 
| CONTROLLER | | INTERPRETER | |{ | INTERFACE | | | SUBROUTINES | | | ROUTINES | 
| SEE TREE 3 { IES TREE 5 | | JSEE TREE 6 | | {SEE TREE 8 | | | SEE TREE 11 | 
Cee oR Se: (hk ee eRe Oe ep eee 2 te a) Qs Wee eos 5 
{ | | 
(Oe cerieeneaecaeennens a0. e-----c SE [tl teeteateetenereeetenenen 
| |USER id 1 | | LOGICAL | 
| | DIAGNOSTIC | | | DYNAMIC | { | VALUE | 
t-4 OUTPUT | t-{ FILE | --4 TESTING | 
| INTERFACE | | SUBROUTINES | ] SUBROUTINES | 
| SEE TREE 6 | |SEE TREE 9 | ree TREE 12 
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(DATA 

J CONVERSION | 
| SUBROUTINES | 
{SEE TREE 12 | 
loo eee ee di 


[BIT, BYTE, & | 
|CHARACTER = | 
—{MANIPULATION | 
|SUBROUTINES |{ 
| SEE TREE 12 | 


FO ee ee oe ee 
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PSECIFICATION TREE 2 


eee |S i 

| EXECUTION | 

| SUPERVISOR | 

{ | 

| Sy -------- di 
| 

ee A A A A ES RT i A A rrr rr nn fn 

I | 

et prt nt 7 


pe ces ces cere ee es ee ee ee cee ee 


(------- 


[ 
| 
| PLAN ~ DFJPLAN 


| | 
{SPECIAL S/360 | 
| OS/DOS SUPPORT | 


pe es es ee ee op ee 


MACRO 


| 
en ee ot ey 


| 
| 
CENTR-ENTRY | 
| 
4 


DPLAN LOADER 
EQUIVALENCE 


a paren 


MACRO 


r 

| \ 
{EPLAN LOADER | 
| EQUIVALENCE | 
| | 
L 4 


ae ye sh ea et en ae 


{ 
| 
REGISTER | 
EQUATE MACRO | 


| DFIRETN 

-j EXECUTION 
| TERMINATION] 
|: PROCESSING | 
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| 

[SPECIAL S/360 | 

| OS SUPPORT | 
| 


DFJCRDIR 


DIRECTORY 
BUILD 


DFJLLIST 
JOBPAC AREA 


PROGRAM 


Cae ea BN 


I 

—] DFJUNC/DFJUMC | 
| FREE STORAGE] 

| CONTROL i 


| 
IN~CORE | 
| 
| 


PROGRAM 


— 
1 
| 
| 
! 
t 
! 
! 
! 


f-----—- 


| 
|SPECIAL S/360 
| DOS SUPPORT 


S$SBDFJD 
TRANSIENT 
DUMP 
ROUTINE 


. 
| $SBDFIDO 
—| TRANSIENT 
| DIRECT- 
| ACCESS 
u 


S$SBDFII 
TRANSIENT 
INITIAL- 
IZATION 
ROUTINE 


SEQUENTIAL 


| 
—j $$BDFJSO 
| 
| FILE OPEN 


DESCRIPTION MANUAL 


DESCRIPTION | 


[ 
| DFJIOBD i 
l 
{| ROUTINE | 
L 


; 
| 1 
4 DFJIOBE { 
| FILE r 
| DESCRIPTION | 
L 


| PLAN COMMON] 
{ DECLARATION| 


{ 
i 
{ 
| 
i 
1 | 
l | 
| t-{DFISYCOM 
1 | 
1 | 
| 
I 
| 
| {DFJCB Ifo | 
t-4 CONTROL | 
| BLOCK | 
| EQUIVALENCE | 
J 
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SPECIFICATION TREE 3 





ewe 1 
| EXECUTION 
| SEQUENCE 
| CONTROLLER | 
ee eo Seca J 
| 
[ono nnn [rrr $o2 —T 
| | I | 
= De cet Sela ere iv, pemecetatend acta! pcan Bote oe 
| { | | |OVERLAY i | 
| MODULE |. {POP-UP LIST {| | STRUCTURE | | COMMAND 
| TERMINATION { | MANIPULATION | | CONTROL | | MANIPULATION 
| ROUTINES | | ROUTINES | ROUTINES in| ROUTINES 
|-—_____-_--—_- —-1 [------------ 1 f---------—---- } f[--------------- 
| | | | 
| orn -—_ | -------"" 01 ecco [pret tr torn 
| |LRET- 1 | |Lrst- | | |LOCAL- LOAD | | |LREPT- REPEAT 
t-4{. TERMINATE | t-4 MANIPULATE { t-4 DEPENDENT | $-4{ PREVIOUS 
1 { MODULE { { | LIST { 1] MODULE | i | COMMAND 
[eee a a, ener DC Metter ee i ee eee 
| | | | 
| ------------- —q | ¢----------—- 1! eoomH,_c —— | «H-----------—- 
{| {tt | | | LNRET- li 
t4 LCHEX- | }—-4 LEX- i LJ TERMINATE | L_.4 PUSH- 
| CHECKPOINT 1 | | LOAD & | | DEPENDENCY | | INSERT NEW 
1 AND EXIT {4 EXECUTE | | CHAIN | | COMMAND 
ee aed it ae J er re J Pets eo Ane ee, 
| 
| 1 
| | LISTB- | 
tf INSERT NAME | 
| AT LIST { 
| BOTTOM | 
Ce J 
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| 
| SPECIAL | 
| 1130 | 
| ROUTINES | 


[ | 
}-41 SAVE PIAN | 


| LOADER | 
L 


LRLD- 
{ RESTORE 
| PLAN 


{ 
| 
I 
| 
| 
L.. 
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fos 1 
| LANGUAGE | 
| COMPILER | 
| | 
Gee ae eer a enon J 

| 

(tn rr rn rrr ern + 

| | 
.[~------ 4--—--— —7 eoew enn ben nn 7 

| PHUDT- 

|PHRAS-DFJPHRAS | | 1130 LANGUAGE | 
| LANGUAGE | DICTIONARY 
| COMPILER | | UPDATER 
ee ee __J En a at RE Ope Set J 
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Gey ge ee ee 1 
| PTDP1-DFIPTDP1 | 
—j COMMAND | 
| HEADING | 


| PIDP2- DFJPTDP2 | 


—{ INITIALIZATION| 


| VALUE { 
DUMP | 


r 1 
| PTDP5-DFJPTDPS5 | 


I 

{ 

| 
b- 

| 

{ 

| 

| 

I 

| 

r 

| 

| 

| 

| 
aE aaeamee 1 
t 

| 

| 

I 

| 

| 
t-4 CHECK 
1 | 
| 
| 

| 

| 

L 


| | 
—{ PTDP6-DFJIPTDP6 | 
| EXPRESSIONS | 
| DUMP | 
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DUMP 


| DICTIONARY 
{ 
L 


toy 
oka 
a 
re 
e 
3 
3 


~ 


| CONTROL 
| ROUTINE 


a 
a 
7 


po es oe Oe ee ee 
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Wor hs Ge Po ey re T 

{ | 

| { 

| | 

{ { 

| { 

[ { 

| I 

[ I 
f—— 4 ---- - -— 7; NS 
I | {PSCNB- 
|PSCAN-DFJPSCAN| | 1130 SCAN 
| SCAN | {| ROUTINE-1130| 
| ROUTINE { | PART 2 
Nace a se se cer ee ee ee eas ne | Cn ce ne se ce ae ew eae se ne ca 
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(attr 1 


j | 
| LANGUAGE { 
| INTERPRETER | 


ee 


pm cee ce ee ee ee ee ee 


| [ 
| |PSTSV-DFIPSTSV| 


| STATEMENT { 
| SAVE | 
Jj 


fee ns cee oes a cee ene eee ae 


a ye en ee pee 1 
| USER | 
| EXIT | 
| ROUTINES | 
fk a a se sis emerson ce is es J 

I b | 


INITIALIZE 
USER EXIT 


| 

| 

| 

t- 

| 

{ 

{ 

[ 

{ 

| |EUSER- 

}-4 EXIT FROM 
| {| USER EXIT 
| 
{ 
| 
{ 

| 
t- 
{ 
I 
| 
| 
[ 
{ 


he cee SUS a ces an 


Wears srt tne oe 1 
| GUSER- | 
4 EXTRACT | 
| INPUT | 
| CHARACTER | 
[| ee J 
poet te ‘ 
| NUSER- 


| 
tJ ACCESS & i 
| INCREMENT | 

| CAP POINTER] 

J 
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l | 
[SPECIAL 1130 | 
| USER EXIT | 
| ROUTINES | 


=== 
cee 
Q 
: 
3 
ce cin as Sn 


EXTENDED 


‘ 
| DUSER- | 
-{ DUMMY | 
| 
{ 
dj 


oe oe 0 ee 


| LIBF 
{ ROUTINE 
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(SY 
{DIAGNOSTIC i 
| SUPERVISOR ! 
eae panies 3 
| 
(rr rn rn rn nnn fn rr nner 41 
| | | 
pat 1 won nt 71 wannabe 7 
| DIAGNOSTIC | | USER | | USER | 
| GENERATOR | | DIAGNOSTIC | | DIAGNOSTIC | 
| AND | { INPUT | | OUTPUT 
| CONTROLLER | { INTERFACE | | INTERFACE | 
Ee ee ne Ae eee eer 5 ee Dae ee | boscuoascouecss r 
| | 1 
| pt oe enn —" | peor 1 | ¢------------- 1 
| | | ERROR- { | | EWRIT- r 
L_.| PERRS-DFJPERRS | }-] ISSUE { t-4 QUEUE | 
| DIAGNOSTIC | | | DIAGNOSTIC | | | FILE { 
| MODULE | | | §& ABORT | | | ACCESS 
Se le ea | “hetestees oe j } kee ee J 
| { 
| crt e nn nnn 7 {| r----------- "1 
|] | ERRET- | | | ERLST- { 
t-4 ISSUE | t-4 QUEUE | 
11 DIAGNOSTIC { | | FILE { 
1 | & RETURN ] {| LIST | 
| Shee es J at Gee eaten RS Em ee J 
| | 
| proton {  ¢---------- 
| |ERREX- { | | ERASABLE | 
t-{ ISSUE 1 L_4 COMMON | 
1 | DIAGNOSTIC | } DIAGNOSTIC | 
1] & EXIT | | TRANSCRIPT | 
{ ee J ge eer aM ET 
| 
I teeeetenetaeeeiensieeeneten | 
| | ERRAT- | 
t4 ISSUE 


{ 
1 DIAGNosTIC | 
| W/DELAY ABORT | 
| Jj 
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etna 1 
| SEQUENTIAL 
| FILE 
| SUBROUTINES | 
Be oe J 
| 
ce CC fn nnn rt een nna 1 
| | | { 
 pneneemeaenineeintenetemeeness Tl Gaminienene t————-———— Qo ptt nt 71 .------- 4 1 
| {| {| { I | 
| INPUT | JourpuT | [DEVICE & {1130 SPECIAL | 
| CONVERSION | | CONVERSION | | DATA | FUNCTION | 
| ROUTINES | | ROUTINES { | CONTROL { {| ROUTINES | 
ee ener aod eae ete D Cte ose j eee ik, ‘saad 
| {  ainneienienienmeaanetnentametearnanes 1 
{ | | | 
| pert -—q | ------------~ 1 e-efh- | pron .) 
| | PAIN- | | | PAOUT- | | |PLINP/PLOUT } | | 
f-{A TO A | f-dA TO A | --1 TRANSFER DATA| }-4S/360 | 
| | INPUT | { | OUTPUT | | | TO/FROM | | | SPECIAL | 
| | CONVERSION | | | CONVERSION ] | | BUFFER { 1 | FUNCTIONS | 
() bexieeceea ees ee ee ee es OG Meas ecute a ee 4 
| | | { 
J porn nnn 010 ew--cc oo q000 ecco 1 1 of" 1 
| | PIIN- | | |PLouT- } | | PBUSY-PIOC | | | PENDF | 
f-{ A TOT | t-4 I TOA | t-4 TEST DEVICE | t-4 CLOSE | 
| | INPUT | | | OUTPUT | { | READY /BUSY | | | SEQUENTIAL | 
| { CONVERSION | | | CONVERSION | | | STATUS | | | DATA SET | 
) Geta OS Beata ott Oe NG CS et DO lai icceane es j 
| | | | 
| poco v0.0 eee 2 === 1 1 
{| | PFIN- { | | PFOUT- 1 | |PBFTR | | | PPAGL | 
tJ A TO F | tj FTOA | t-4 TRANSFER | +-4 DEFINE | 
| INPUT 1 | | OUTPUT | 1 1 BETWEEN iff PAGE { 
| CONVERSION | | | CONVERSION| | | BUFFERS it LENGTH | 
| enaee ieoniy ca) eerie D0 hedar we TE fae resents eieen raion aay (Ma erase eer r 
| | | 
|c_-- omeey | perme 900 ecco 1 
{ | PEOUT— ! {| |PCCTL | | | DFJPLENG | 
t-4 F TO ACE) | t-4 DEVICE | t_4 SET | 
| OUTPUT | | | CONTROL | | PAGE | 
| CONVERSION | 1] FUNCTIONS | | LENGTH | 
ara Renae Puree i eee oes J it Ae ge 3 
| 
| occ 1 
| | PEOF | 
L.-j TEXT | 
] END-OF-FILE | 
| STATUS | 
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nea 1 
‘| PERMANENT | 
| FILE | 
| SUBROUTINES | 
Weis cees es ec ccs ce aera Hee Jj 
H 
aici 7 ‘ae ea } ‘aan i 
{16-BIT | |32-BIT | | SORT/MERGE | 
| ROUTINES | | ROUTINES | | ROUTINES i 
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j Meare erent : ds a ss ew sie —— J Cee ees H aca ad ces me J ~~ aud 
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{| PERMANENT | {. PERMANENT | | PERMANENT | i 
| FILE j | FILE { | FILES { | 
We Ss ee es es ere a | ne | Coe eS Jd | 
Coo ee q 
| DFJGSRTB- | | 
| SORT }-------- ] 
| PERMANENT | | 
| FILES { i 
bose eee J | 
Ce oe ee 4 
| DF JGMERG- | | 
| MERGE TWO --------- 4 
| PERMANENT | 
| FILES | 
ese ie eee Jj 
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Rou. 1 
| DYNAMIC | 
| FILE | 
| SUBROUTINES | 
Stes de acs Saar J 
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[orn t oe Tors ee fo a 
| | | 
------- 1—----— —4 | ------ 4--—--——~ 1 
| { | | 
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{-------------- a= | -----------—----— 4 
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| FILE SPACE | | ROUTINE Itt SPACE | 
i eer Sar Seay Welges a ae J -||  Uetecte eee j 
| | 
i" —1 | per cc cen 5] 
1 | | | | 
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t-4 TRANSFER | --{ EXISTENT | 
{ | DATA TO | | FILE OPEN | 
1 | MEMORY | | /COND ET LONBLEY 
Ube eae ee aco ( Saaeee 4 
| | 
| ptteeee — (-7------ eoee—y | ---------- 1 
| |PwRT1- | |PFSPC- | | |READ- 
1-4 TRANSFER { | DETERMINE }-4-] TRANSFER 
| | DATA TO { || UNALLOCATED | | [| DATA TO { 
| | FILE | | SPACE | 1 | MEMORY | 
( Geeta ceeeees Beek Oe ee aren AE (gg ee eee ce j 
| | 
It cereececeteteneteranenet 100 ptt 11. ec 1 
{ { PRELI- | | PFIND- { | {WRITE- | 
tj DEALLOCATE | | 1130 t-+-1 TRANSFER | 
{ FILE | FUNCTIONAL | | | DATA TO | 
| SPACE | | OVERLAYS It] FILE | 
Poweoe ote nok Re ee Wee eat J 
| 
| e-c----- --1 
| | RELES- | 
L-4 DEALLOCATE § | 
| FILE | 
I SPACE | 
Gees easy 
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| | | | DUMP 
| | | | | ROUTINES | 
| ‘| | | ------~-------- 4 
| | | 1 | 
‘----— Lee “yO eo en ann Q promt eter en nnn 1 on domme enwey | penn 1 
| 1 | | i | | | {PCDMP- | 
| INPUT- | | PLOCS-DFJPIOCS | | Locs-~ | | DFJTR-DFJ TRACE] | | DF JPCDMP | 
| ACCESS | | SET I/0 | { SET I70 | | DYNAMIC | t-4 DUMP | 
| COMMAND | | UNITS | | UNITS | | TRACE | j | COMMUNICA- | 
| IMAGE | 1 MODULE | i] SUBROUTINE | | | | | TION ARRAY | 
Go ee Sg ee ee es Wate a ee ae sccm 2. Piece J 
c----— 1 .01 esnsHhcclc 
| | | | PEDMP- 
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{| SET 1130 | t-4 DUMP ERROR | 
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| LIMITS oe | FILE | 
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| r--c--------- 1 
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| PREVIOUS | 
| COMMAND | 
eae AO ete i 
SPECIFICATION TREE 11 enn seete ess 
| ARRAY & | 
| TABLE | 
| PROCESSOR | 
| ROUTINES | 
eee Saino, J 
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[orn or rnb nnn nny 
| | | I 
| eo —1 | ¢---------- 4 = 1 | esfh,-_------- 1 
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| VALUES | | ARRAY | | FILE | { FILE | 
Use tes ee eneeen | Gee ees bootie eee as 5 ar aes J 
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The following definitions reflect context 
and usage within this manual and in other 
manuals related to the PLAN system. 


Abort. An action resulting from detection 
by PLAN of an error. The current PLAN 
module is terminated, all programs in the 
pop-up list are skipped, and processing 
starts at the next equal- or higher-level 
command. 


Arguments. A list indicating data that is 
to be made available to a new operation. 


CAP. An abbreviation for communication 
array position. It represents the sub- 
script to which a data name is 
equivalenced. 


Check Entry. A definition within a phrase 
definition of tests to be made and actions 
to be made as a result of the test on data 
in the communication array. 


Command. The phrase and modifying verbs 
indicating the indexed dictionary procedure 
to be followed. 


COMMON. A FORTRAN or Assembler statement 
(source or control) that specifies 
variables and variable arrays that are to 
be placed in an area of core storage 
protected from overlay by program-loading 
operations. 


Communication array. An array of data 
residing in COMMON used for transmittal of 


data from module to module and from the 
PLAN language interpreter to modules. 
Constants. Data with a fixed numeric, 
logical, or alphmeric value. 


Data. Input to or output from an 
operation. 


Dictionary. An indexed data file contain- 
ing the condensed syntactical text of a 
language. Indexed file of user's language. 


Dimension. A FORTRAN source statement that 
defines the size of a data array for which 
storage is to be allocated. 


DUMP _ COMMON. A PLAN command to print the 
contents of the communication array. 


DUMP MANAGED. A PLAN command to print only 
the managed portion of the communication 
array. : 
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DUMP NONMANAGED. A PLAN command to print 
only the nonmanaged portion of the communi- 
cation array. 


DUMP _ PERMANENT. A PLAN command to print 
the contents of a PLAN PERMANENT file. 


DUMP DYNAMIC. A PLAN command to print the 
contents of a PLAN DYNAMIC file. 


DUMP SWITCHES. A PLAN command to print the 
contents of the 15 PLAN switch words. 


Elements. The syntactical portion of a 
statement required to define a data item. 


EQUIVALENCE. A. FORTRAN source statement 
that specifies variable names and array 


names that are to be set equal to the 
location in memory. 
only addressing; 
data transfer. 


same 
This statement affects 
it does not effect any 


Evaluate. Determine a result on the basis 
of a series of procedural steps to be 
performed on data. 


Extended precision. The size Of a FORTRAN 
variable word greater than that defined by 
ASA standard FORTRAN. 


FORMAT. A FORTRAN’ statement used to 
describe the physical organization of an 
input or output record. FORMAT is also 
used to describe the syntactical organiza- 
tion of data. 


Interpreter. A program(s) that examines a 
language syntax and links to a series of 
programmed steps to effect a task solution 
without generating specific computer code 
for the task. 


Iocs. A PLAN statement to allow the chang- 
ing of input and output devices. 


Language. A syntactically correct text 
stream that is input to a particular 
processor. 

Loader. A computer program with the capa- 


bility of retrieving a module from the 
program library and placing it in core 
storage in a form ready for execution. 


Managed array. A portion of the communica- 
tion array whose data content is maintained 
according to a language associated level 
(dependence) structure. 


Module. 
ciated 


A mainline program and its asso- 
subroutines stored in the program 
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library in a form appropriate for execution 
within PLAN. 


Nonmanaged array. The portion of the com 
munication array not in the managed array. 


Operands. The data upon which operations 
are to be performed. 


Operator. An arithmetic or logical symbol 
indicating an operation (add, and, or, 
multiply) that is to be performed on data. 


Pack. The process of placing an EBCDIC 
character into a PLAN (32-bit) word. 


Phrase. 
statement that becomes 
dictionary index. 


The name assigned to a language 
the identifiable 


PLAN level error recovery. : An action 
resulting from detection by PLAN of an 


error. The current PLAN module is ter- 
minated, all programs in the pop-up list 
are skipped, and processing starts at the 
next equal- or higher-level command. 


Program. A group Of FORTRAN or Assembly 
language source statements processed as one 
compilation or assembly. 


Program list. Program names or program 
numbers maintained in a push-down, pop-up 
list where the top of the list always 
indicates the next program to be loaded. 
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statement 


Scan. The process of examining 
syntax to determine correctness and 
meaning. 


Standard precision. The standard size of a 
FORTRAN variable word defined by ASA stand- 
ard FORTRAN. 


Statement. An entity input to a processor 
consisting of the alphameric text. 


Store. The process of placing a program 
into the program library or data into a 
core storage facility. 


Switch Words. A group Of 15 32-bit words 
that provide communication of control 
information between PLAN and user modules 
and between user modules. 


Unpack. The process of extracting EBCDIC 
characters from a PLAN word. 


UREND. A logical end-of-file indicator for 
PLAN data files. 

Variables. Data with changing numeric, 
logical, or alphameric values. 


Verb. A phrase that modifies 
and syntax of another phrase. 
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Items in this index are arranged alphabet- 
ically. Entries include module names, sub- 
routine names, phrase names, 
and language definer characters. Numeric 
section in which 
or examples of use 


references define the 
pertinent explanations 


ADD PHRASE 


ALTER PHRASE 
arithmetic 


BREAK 
CAP index 


CARD 
checking 


command 


communication array 


conditional 
constant 
data 


data names 


data values 
default values 
DELETE PHRASE 


DUMP COMMON 
DUMP DYNAMIC 
DUMP ERRORS 
DUMP MANAGED 
DUMP NONMANAGED 
DUMP PERMANENT 
DUMP PHRASES 
DUMP SWITCHES 
erasable COMMON 
ERLST 

ERRAT 

ERRET 

ERREX 

ERROR 

EUSER 

EWRIT 

EXECUTE 

EXIT1 
expressions 


FALSE 
FIND 


formula numbers 
GDATA 


GDAT1 
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may be found. The exact page of the 
reference may be found by locating the 
section reference number in the table of 
contents. Primary references are 
underlined. 


PLAN terms, 


























3.3.0, 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.22.4, 4.3.0, 
~4.3.3, 4.3.12, 4.4.0, 4.5.3 

3.3.0, 4.3.0, 4.5.2 © 

4.1.6, 4.1.10, 4.1.11, 4.1.12, 4.3.3, 4.3.8, 4.3.10, 
4.3.16, 4.4.0 

5.11.0, 5.11.11 

4.1.9, 4.2.2, 4.2.4, 4.3.3, 4.3.6, 4.3.7, 4.3.8, 
4.3.9, 4.3.10, 4.3.12, 4.3.15, 4.3.16, 4.3.24, 4.4.0 
4.5.12, 8.5.0 

4.3.15, 4.3.20, 4.3.23, 4.3.24, 4.3.25, 4.3.26, 4.4.0, 
12.1.9 

4.1.4, 4.1.5, 4.1.6, 4.2.0, 4.2.1, 4.3.0, 4.3.3, 4.3.5 
4.4.0 

3.2.0, 4.1.0, 4.2.0, 4.24.4, 4.3.3, 4.3.6, 4.3.11 
4.3.21, 4.3.23, 4.5.4, 4.5.7, 6.1.0, 8.2.0, 9.2.0, 
9.5.0 10.2.0, 10.15.0 

4.3.17, 4.4.0 

§.1.8, 4.4.0, 12.1.6 

4.1.5, 4.1.6, 4.2.0, 4.3.2, 4.3.19, 4.3.25, 4.23.26, 
4.4.0 : 

4.1.6, 4.1.7, 4.2.2, 4.2.4, 4.3.9, 4.3.10, 4.3.18, 
4.3.24, 4.3. 26, 4.4 4.0 

4.1.6, 4.2.3, 4.2.5, 4.4.0 

4.3.12, 4.3.24, 4.3.25, 4.3.26, 4.4.0, 12.1.6 

3.3.0, 4.3.0, 4.3.3 4.3.5, 4.3.15, 4.3.19, 4.5.2, 
9.7.0, 

3.5.0, 4.3.21, 4.5.7 

3.5.0, 4.3.21, 4.5.9 

3.5.0, 4.5.11 

3.5.0, 4.3.21, 4.5.7 

3.5.0, 4.3.3, 4.3.21, 4.5.7 

3.5.0, 4.3.21, 4.5.8 

3.5.0, 4.3.21, 4.5.10 

3.5.0, 4.3.21, 4.5.7 

4.3.21, 4.5.7, 4.5.8, 4.5.9 

3.4.0, 4.3.21, 5.3.0, 5.11.6 

3.4.0, 4.3.18, 4.3.21, 5.3.0, 5.11.6, 8.9.0, 13.1.0 
3.4.0, 4.3.21, 5.3.0, 5.11.6, 5.11.9, 8.9.0, 13.1.0 
3.4.0, 4.3.21, 5.3.0, 5.11.6, 8.9.0, 13.1.0 

3.4.0, 4.3.21, 5.3.0, 5.11.6, 5.11.9, 8.9.0, 13.1.0 
4.3.18 

5.3.0, 5.11.6 

3.5.0, 4.3.23, 4.5.9 

4.3.19, 8.8.0 

4.1.10, 4.1.11, 4.2.4, 4.3.15, 4.3.16, 4.3.17 4.3.20, 
4.3.24, 4.3.25, 4.3.26, 4.4.0, 12.1.10 

4.1.6, 4.1.12, 4.1.13, 4.2.3, 4.3.3, 4.3.15, 4.3.16, 
5.7.0, 5.11.5 

5.5.0, 5.11.2, 8.3.0, 8.6.0, 9.3.0, 10.13,0, 10.17.00, 
12.2.9 

4.2.6, 4.3.20, 4.4.0 

4.5.5, 5.4.0, 5.11.3, 8.3.0, 8.7.0, 8.9.0, 9.4.0, 
9.10.0 10.13.0, 10.16.0, 12.3.0, 14.0.0 

4.5.6, 


5.4.0, 5.11.4, 8.9.0 
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GMRGA 3.5.0, 9.15.0, 10.21.0, 13.7.0 

GMERG 3.5.0, 9.15.0, 10.21.0, 13.7.0 

GSORT 3.5.0, 9.15.0, 10.21.0, 13.7.0 

GSRTA 3.5.0, 9.15.0, 10.21.0, 13.7.0 

GSRTB 3.5.0, 9.15.0, 10.21.0, 13.7.0 

GTVAL 5.10.0, 5.11.10 

GUSER 4.3.18 

INPUT 4.5.13, 5.6.0, 5.11.5, 8.9.0 

Tocs 3.5.0, 8.3.21, 4.5.8, 4.45.12, 5.2.0, 5.11.5, 8.5.0, 
9.5.0, 10.18.0 

TUSER 4.3.18 

LCHEX 4.3.4, 5.1.0, 5.8.0, 5.11.1, 8.9.0, 9.10.0, 10.12.0, 
10.13.0 

level 3.2.0, 4.2.1, 4.2.3, 4.3.3, 4.3.19, 4.4.0 

LEX &.3.15, 5.1.0, 5.11.1, 5.11.2, 8.3.0, 8.9.0 

LIST 4.3.14, 4.3.15, 5.1.0, 5.11.1, 8.3.0, 8.9.0, 9.6.0 

LISTB 5.1.0, 5.11.1, 8.9.0 

LIST LITERAL 3.5.0, 4.5.6 

literal 4.1.6, 4.1.9, 4.2.3, 4.4.0 

LNRET 5.1.0, 5.11.1, 8.9.0 

LOCAL 4.3.15, 5.1.0, 5.11.1, 8.4.0, 8.9.0, 9.3.0, 9.9.0, 
10.4.0, 10.6.0 10.12.0 

logical 4.1.6, 4.1.7, 4.1.12, 4.2.3, 4.3.15, 4.3.17, 4.4.0 

LREPT 4.3.5, 4.3.15, 5.1.0, 5.11.1 

LRET $21.0, 5.11.1; 5.11.2, 5611.8,. 5.11.9, 5611.10; 74320; 
8.3.0, 8.9.0, 9.6.0, 9.8.0, 10.7.0 

LRLD 8.9.0, 14.0.0 

LSAV 8.9.0, 14.0.0 

Managed communication 

array 2-5-0, 3.2.0, 4.3.3, 4.3.21, 4.3.25, 4.5.4, 6.1.0 

mode 4.3.14, 4.3.18, 4.3.24, 4.3.26, 4.4.0, 12.1.7 

modules 4.1.5 

NDEF 37.0, 5.11.5, 7.3.0 

numeric 4.2.3, 4.2.6 

NUSER 4.3.18 

OBJECT 4.1.4, 4.3.5 

PAIN 5.9.0, 5.11.9 

PAOUT 5.9.0, 5.11.9; 7.«3.0 

PARGI 4.3.22, 5.10.0, 5.11.10 

PARGO 4.3.22, 5.10.0, 5.11.10 

PBFTR 5.9.0, 5.11.9 

PBIST 5.10.0, 5.11.11 

PBUSY 5.9.0, 5.11.9 

PCCTL 5.9.0, 5.11.8, 9.10.0, 10.19.0 

PCDMP 3.5.0,. 6.5.27 

PCOMP 5.10.0, 5.11.11 

PDBFA 5.9.0, 5.11.9 

PDBFB 5.9.0, 5.11.9 

PDBFC 5.9.0, 5.11.9 

PDBFD 5.9.0, 5.11.9 

PDBFE 5.9.0, 5.11.9 

PDIAG 3.5.0, 4.5.5 

PEDMP 3.5.0, 4.5.11 

PENDF 9.14.0, 10.19.0 

PENRM 8.8.0 

PEOF 5.9.0, 5.11.9, 9.10.0, 10.19.0 

PEOUT 5.9.0, 5.11.9 

PEPCK 5.8.0 

PERRS 3.1.0, 3.2.0, 3.3.0, 3.4.0, 4.3.21, 4.5.4, 5.3.0, 
8.9.0, 6.1.0 13.0.0, 14.0.0 

PEXTP 8.8.0 

-PEUPK 8.8.0 

PFDMP 3.5.0, 4.5.8 

PFILE 3.1.0, 3.3.0, 3.5.0, 4.1.0, 4.3.0, 4.3.3, 4.3.8, 
4.3.11, 12.1.0 

PFIN 5.9.0, 5.11.9 

PFIND 3.5.0 

PFND1 5.5.0, 5.11.4 
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PFOUT 
PFSPC 
PHIN 

PHRAS 


phrase 
PHOUT 
PHTOE 
PHUDT 
PIDMP 
PIIN 
PIOc 
PIOCS 
PIOUT 
PIPCK 
PIUPK 
PLAN 
PLAN JOB 
PLENG 
PLINP 
PLNUP 
PLOUT 


PLITL 
PMERG 
PMRGA 
pop-up list 


PPACK 
PPAGL 
PRED1 
PRED1 
program 
PSBFA 
PSBFA 
PSBFB 
PSBFC 
PSBFD 
PSBFE 
PSCAN 


PSORT 
PSRTA 
PSRTB 
PSTSV 
PTDMP 
PUNPK 
PUSH 

PWRT1 
RDATA 


RDAT1 
relational 

READ 

RELES 

SAVE 

saved statement 
scale factors 
SEND 

SET LITERAL 

SET PAGE LENGTH 
statement 

STVAL 

subscript 


switch words 


symbol tables 
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test mask 4.1.12, 
TRUE 4.1.6, 
4.3.26 
TYPE 4.5.12, 
UREND 5.11.9 
user exit 4.3.18, 
12.1.11 

VERB 4.3.5, 
VERB PHRASE 4.1.3, 
WDATA 5.4.0, 
12.3.0 

WDAT1 5.4.0, 
word 4.1.0, 
WRITE 5.5.0, 
A 4.3.15 
b (blank) 4.1.1, 
Cc 4.3.15 
E 4.1.7, 
F 4.3.15 
I 4.3.14, 
P 4.3.13, 
R 4.3.15 

Ss 4.3.9 
T 4.3.15 
U 4.3.18 

0 (Zero) 4.3.4 
& (and) 4.1.13, 
* (asterisk) 4.1.10, 
9.10.0 

# (BCD equal) {.3<6L; 
a (BCD quote) 4.1.9, 
: (colon) 4.1.12, 
4.3.18, 

(comma) 4.1.5, 
4.3.16, 

§ (dollar sign) 4.2.6, 
" (double quote) 4.1.9, 
= (equal) 4.1.10, 
4.3.20 

! (exclamation point) 4.2.6, 
> (greater than) 4.1.12, 
( (left paren) 4.1.11, 
4.3.16, 
< (less than) 4.1.12, 
- (minus) 4.1.10, 
4.3.18, 
, (not) 4.1.13, 
| (or) 4.1.13, 

e (period) 4.2.2 
+ (plus) 4.1.10, 
4.3.20 

? (question mark) 4.2.6, 
*" (quote) 4.1.9, 
») (right paren) 4.1.13, 
4.3.16, 

; (semicolon) 4.1.5, 
7 (slash) 4.1.10, 
(underline) 4.1.12 
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4.1.12, 4.1.13, 4.2.3, 4.3.15, 4.3.16, 4.3.25, 
5.11.5 
8.5.0 
4.3.19, 4.3.2u, 4.4.0, 8.1.0, 9.4.0, 10.14.0, 
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5.11.4, 8.9.0 
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4.1.10, 4.1.11, 4.1.12, 4.2.0, 4.3.18, 
4.1.11, 4.1.12, 4.2.4, 4.2.6, 4.3.16, 4.3.18, 
4.3.1/, 4.3.20 
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4.2.3, 4.2.4, 4.3.9, 4.3.13, 4.3.16, 4.3.18, 
4.3.17, 4.3.20 
4.1.10, u.2.2, 4.3.9, 4.3.15, 4.3.18 
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SPECIFICATION TREE 10 (rrr nnn ne 1 
[STANDARD PLAN | 
| COMMANDS & | 
| SUPPORTING | 
| MODULES | 
ey 
| 
frost toe [ort t rn fron “yo ----- << 1 
| | | | | 
| | | | ------ Seam men me 5] 
1 | | | | UTILITY | 
| | | | | DUMP 
| | | | | ROUTINES | 
| | { | }-------------- 4 
| | | | | 
‘----- 4—————— —q pct 1a — —q 0 prone tennn nn 5 EE Gece dameeenneny | pom 1 
| 1 | i 1 i | | | | PCDMP- { 
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| | | PEDMP- 
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| DUMP i 1 { QUEUE 
| LIMITS tid FILE 
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| | DFOPFDMP | 
f-4{ DUMP FILES | 
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| | DYNAMIC | 
| heeetecwsecee J 
| 
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| | PIDMP- | 
| | DFJPIDMP | 
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| PREVIOUS | 
| COMMAND | 
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| TABLE | 
| PROCESSOR | 
| ROUTINES 
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L_4 STVAL-— | tj DATA INTO t-4 TABLES FROM | ‘4-4 LIST | 
| STORE | | COMMUNICATION | | MEMORY TO | | TABLE | 
| VALUES | | ARRAY ] | FILE | | FILE | 
peep ee ieee RE reese eee re J Kee er hey Dee eee rsa edie J 


ANALYSIS DIAGRAMS 177 


LBM PRUBLEM LANGUAGE ANALIGBR UruAns 


PROGRAM DESCRIPTION MANUAL 


SPECIFICATION TREE 12 


| LOGICAL 
| VALUE 
| TESTING 


ene ee 


NDEF-~ 
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faces 1 
{ AUXILLIARY | 
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| DATA { | CHARACTER 
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| | 
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19.0.0 APPENDIX L: COMMUNICATION ARRAY LAYOUT CHART 


The chart in this section may be copied and 
used for planning the utilization of the 
communication array layout. 
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DATE: 
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